[kuschku]

> There's no point returning an error and letting the program try to recover, just blow up with as much information as you can, so the bug can be fixed.

Well, imagine a game letting the user roll a dice. "Chose a number of sides for your dice".

In such cases, handling such a panic might be useful. And knowing that it exists might be useful, too.

If the language does not allow specifying a range of a type (for example, requiring all numbers passed into the RNG to be positive), then it should be specified in the API in other ways programmatically, so it can be statically analyzed.

[cube2222]

You should ALWAYS check the input you get from users. So this really wasn't a good counter argument.

[kuschku]

As I said above, panics should ideally never be able to occur, but be part of the type system.

In languages with dependent types, for example, it’s common to represent a Stack in a way that number and type of elements are stored in the type (so you can’t even pull from an empty stack – that’d be a compile time error).

In the same way, the random number generator should either return an error, or use a number type that can only encode positive numbers as input.

Especially if combined with the interface{} everywhere across the new stdlib functions this all smells very much like C's problems.