[geoka9]

> Panic is pretty much never used (so you don't really have to think if the previous statement can panic. If it does it means something is SO wrong that your application can't continue anyways because it's broken)

That's it. I think OP just assumed panics in Go are what exceptions are in other languages.

[kuschku]

Because the stdlib is using them more and more? As someone mentioned, even closing an already closed channel can panic. Calling the random number generator with a negative limit panics.

And there’s nothing like checked Panics so you’d know if one will happen or not.

[cube2222]

As I said, if your code is plainly wrong then I see no problem in it going haywire. The channel rules are widely known -> you know, it takes more than a few days to learn a language, there are a few rules to learn too.

Calling a number generator with a negative limit is also a programmer fault, so no reason to provide an error here.

[candiodari]

Yes, there is no problem as long as you agree with X about what is a "real" error and what isn't.

X includes

the language authors (who are using this more and more in the stdlib as pointed out elsewhere)

the authors of any library you use ... but

transitively, so this includes the authors of any library you use indirectly as well

Hmmmm ... what was the problem with (unchecked, or python's) exceptions again ?

[geoka9]

I see nothing wrong with that - those _are_ fatal conditions that indicate that something is dangerously wrong in the program.

And those panics do give you a helpful stack trace, complete with source code line numbers, so it's easy to find the culprit (as opposed to "bubbling up" exceptions).

[twic]

These uses of panic look a lot like the canonical use of unchecked exceptions in Java: the programmer has made an error, which they could have avoided. It's a bug. 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.

The canonical use of checked exceptions in Java is for unpredictable events - almost always related to interaction with the outside world, like IO, networking, parsing, etc. These are things the programmer can't prevent, and must defend against, so the type system allows, and in fact forces, the programmer to explicitly address them.

This is all explained beautifully, and at length, in this monograph:

http://joeduffyblog.com/2016/02/07/the-error-model/

[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.