4 ms·

> panic and recover are best reserved for exceptional circumstances. You might go with Joshua Bloch and say exceptions are also best reserved for exceptional c

by rob74 2y ago

> panic and recover are best reserved for exceptional circumstances. You might go with Joshua Bloch and say exceptions are also best reserved for exceptional circumstances (which actually only means "things aren't working as expected"), that's why Go's authors used "panic" instead of "throw" or something similar, to make clear that it shouldn't be used where you might use exceptions in other languages. I mean, it's in the FAQ too: https://go.dev/doc/faq#exceptions https://go.dev/doc/faq#exceptions

9rx 2y ago
> which actually only means "things aren't working as expected" Exceptional circumstances, or exceptions for short, mean "things aren't working as expected due to programmer error". In other words, a situation that theoretically could have been avoided by a sufficiently advanced compiler but that wasn't caught until runtime. "things aren't working as expected" is vague enough to include errors, which are decidedly not exceptions. One might say a hard drive crash or the network failing isn't working as expected, but those situations are not exceptional. > to make clear that it shouldn't be used where you might use exceptions in other languages. Other languages are starting to learn that you shouldn't use exception handlers where you wouldn't use panic/recover, so I'm not sure there is a practical difference here.
- bazoom42 2y ago
  Terminology is a problem here. A crashed harddisk is clearly an exceptional circumstance. More specific terms is needed to distinguish errors in the code (eg divide by zero) from unpreventable errors like network failure.
  - tored 2y ago
    Isn't that what we have exception hierarchies for?
  - 9rx 2y ago
    > A crashed harddisk is clearly an exceptional circumstance. It is clearly not. It is very much something to anticipate. At sufficient scale, it is guaranteed that it will happen. There is nothing exceptional about it. > More specific terms is needed to distinguish errors in the code (eg divide by zero) from unpreventable errors like network failure. Luckily we have such terminology already: Exceptions (caused by mistakes in the code) and errors (caused by external faults).
    - daveliepmann 2y ago
      In what context is this terminology standardized?
      - 9rx 2y ago
        Terminology is never standardized. Language doesn't work like that. How, exactly, does one manage to exist in this world and not know that...? However, outside of the Java world, which flips the terms around for some reason, this seems to be the prevailing usage. It is also the only usage that makes sense based on what seems to be the prevailing understanding of what "error" and "exceptional" mean. Java's "exceptional conditions" being the ones that you expect to happen regularly doesn't make sense, but was presumably an accident in naming that just so managed to stick. Of course, confusion is compounded by some language idioms using exception handling constructs to handle errors.
- daveliepmann 2y ago
  >Exceptional circumstances, or exceptions for short, mean "things aren't working as expected due to programmer error". Interesting. In Javaland this describes assertions, and the term exception is for operating errors, i.e. problems not necessarily attributable to programmer error, including your example of a network failure.
  - ignoramous 2y ago
    > In Javaland this describes assertions, and the term exception is for operating errors, i.e. problems not necessarily attributable to programmer error Making matters more confusing in Javaland, Errors are separate from Exceptions, but both are Throwables. An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch. Most such errors are abnormal conditions. The ThreadDeath error, though a "normal" condition, is also a subclass of Error because most applications should not try to catch it. https://docs.oracle.com/javase/8/docs/api/java/lang/Error.html https://docs.oracle.com/javase/8/docs/api/java/lang/Error.ht... / https://archive.vn/i5F7B https://archive.vn/i5F7B
    - chuckadams 2y ago
      Errors are not checked, the assumption being that most of the time you can’t do anything about them anyway.
    - PeeMcGee 2y ago
      This reminds me of one of my favorite SO answer-rants that reads like an angry Dr. Seuss rhyme: https://stackoverflow.com/a/36627158 https://stackoverflow.com/a/36627158 > Which of these are the "checked" exceptions? Throwables are checked exceptions, except if they're also Errors, which are unchecked exceptions, and then there's the Exceptions, which are also Throwables and are the main type of checked exception, except there's one exception to that too, which is that if they are also RuntimeExceptions, because that's the other kind of unchecked exception.
      - jacinda 2y ago
- trallnag 2y ago
  In Java I always see exceptions being used for stuff like validating HTTP requests
aqueueaqueue 2y ago
You know why I hate exceptions most? When debugging be it C# or JS, neither the "break on all exceptions" or "break on caught exceptions" are useful on any app. One just hits random library shit, or whatever bloat is in the codebase all the time and the other won't break at all. But because exceptions are the control flow that is the only way to debug them (or do a human binary search) Not sure what go debugging is like but I imagine you can quickly work your way to the first err!=nil while debugging.
- 7bit 2y ago
  You can limit those to code you write. But it sounds like you break also on code that you didn't write eg, libraries or modules. Of course you're miserable.
  - aqueueaqueue 2y ago
    Tell me the dev console option to not do that and I'll use it. I admit it has been a while since I front ended.
- sapiogram 2y ago
  The go standard library also recovers from panics internally in some places, for example for gradient descent parsers.
- rs186 2y ago
  Well, "break on exceptions" can be very powerful when used correctly, i.e. when the scope is narrowed down. It should never be a flag that is turned on all the time -- that's guaranteed misery there. > quickly work your way to the first err != nil while debugging I doubt you'll spend any less time debugging in Go. If you disagree, I'd love to see a "side-by-side" comparison for code that's functionally the same but written in both Go and JS, and see some explanations why it's easier in Go
  - BobbyJo 2y ago
    I've shipped code in JS, Python, C++, Java, Golang, and a few others. I can say with certainty Golang was the easiest to debug simply because if a layer could fail, it was explicitly obvious. Exceptions might come from a few layers deep, and you don't know that until one gets raised.
wetpaws 2y ago
[dead]

by rob74 2y ago

9rx 2y ago

> which actually only means "things aren't working as expected" Exceptional circumstances, or exceptions for short, mean "things aren't working as expected due to programmer error". In other words, a situation that theoretically could have been avoided by a sufficiently advanced compiler but that wasn't caught until runtime. "things aren't working as expected" is vague enough to include errors, which are decidedly not exceptions. One might say a hard drive crash or the network failing isn't working as expected, but those situations are not exceptional. > to make clear that it shouldn't be used where you might use exceptions in other languages. Other languages are starting to learn that you shouldn't use exception handlers where you wouldn't use panic/recover, so I'm not sure there is a practical difference here.

bazoom42 2y ago
Terminology is a problem here. A crashed harddisk is clearly an exceptional circumstance. More specific terms is needed to distinguish errors in the code (eg divide by zero) from unpreventable errors like network failure.
- tored 2y ago
  Isn't that what we have exception hierarchies for?
- 9rx 2y ago
  > A crashed harddisk is clearly an exceptional circumstance. It is clearly not. It is very much something to anticipate. At sufficient scale, it is guaranteed that it will happen. There is nothing exceptional about it. > More specific terms is needed to distinguish errors in the code (eg divide by zero) from unpreventable errors like network failure. Luckily we have such terminology already: Exceptions (caused by mistakes in the code) and errors (caused by external faults).
  - daveliepmann 2y ago
    In what context is this terminology standardized?
    - 9rx 2y ago
      Terminology is never standardized. Language doesn't work like that. How, exactly, does one manage to exist in this world and not know that...? However, outside of the Java world, which flips the terms around for some reason, this seems to be the prevailing usage. It is also the only usage that makes sense based on what seems to be the prevailing understanding of what "error" and "exceptional" mean. Java's "exceptional conditions" being the ones that you expect to happen regularly doesn't make sense, but was presumably an accident in naming that just so managed to stick. Of course, confusion is compounded by some language idioms using exception handling constructs to handle errors.
daveliepmann 2y ago
>Exceptional circumstances, or exceptions for short, mean "things aren't working as expected due to programmer error". Interesting. In Javaland this describes assertions, and the term exception is for operating errors, i.e. problems not necessarily attributable to programmer error, including your example of a network failure.
- ignoramous 2y ago
  > In Javaland this describes assertions, and the term exception is for operating errors, i.e. problems not necessarily attributable to programmer error Making matters more confusing in Javaland, Errors are separate from Exceptions, but both are Throwables. An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch. Most such errors are abnormal conditions. The ThreadDeath error, though a "normal" condition, is also a subclass of Error because most applications should not try to catch it. https://docs.oracle.com/javase/8/docs/api/java/lang/Error.html https://docs.oracle.com/javase/8/docs/api/java/lang/Error.ht... / https://archive.vn/i5F7B https://archive.vn/i5F7B
  - chuckadams 2y ago
    Errors are not checked, the assumption being that most of the time you can’t do anything about them anyway.
  - PeeMcGee 2y ago
    This reminds me of one of my favorite SO answer-rants that reads like an angry Dr. Seuss rhyme: https://stackoverflow.com/a/36627158 https://stackoverflow.com/a/36627158 > Which of these are the "checked" exceptions? Throwables are checked exceptions, except if they're also Errors, which are unchecked exceptions, and then there's the Exceptions, which are also Throwables and are the main type of checked exception, except there's one exception to that too, which is that if they are also RuntimeExceptions, because that's the other kind of unchecked exception.
    - jacinda 2y ago
trallnag 2y ago
In Java I always see exceptions being used for stuff like validating HTTP requests

aqueueaqueue 2y ago

You know why I hate exceptions most? When debugging be it C# or JS, neither the "break on all exceptions" or "break on caught exceptions" are useful on any app. One just hits random library shit, or whatever bloat is in the codebase all the time and the other won't break at all. But because exceptions are the control flow that is the only way to debug them (or do a human binary search) Not sure what go debugging is like but I imagine you can quickly work your way to the first err!=nil while debugging.

7bit 2y ago
You can limit those to code you write. But it sounds like you break also on code that you didn't write eg, libraries or modules. Of course you're miserable.
- aqueueaqueue 2y ago
  Tell me the dev console option to not do that and I'll use it. I admit it has been a while since I front ended.
sapiogram 2y ago
The go standard library also recovers from panics internally in some places, for example for gradient descent parsers.
rs186 2y ago
Well, "break on exceptions" can be very powerful when used correctly, i.e. when the scope is narrowed down. It should never be a flag that is turned on all the time -- that's guaranteed misery there. > quickly work your way to the first err != nil while debugging I doubt you'll spend any less time debugging in Go. If you disagree, I'd love to see a "side-by-side" comparison for code that's functionally the same but written in both Go and JS, and see some explanations why it's easier in Go
- BobbyJo 2y ago
  I've shipped code in JS, Python, C++, Java, Golang, and a few others. I can say with certainty Golang was the easiest to debug simply because if a layer could fail, it was explicitly obvious. Exceptions might come from a few layers deep, and you don't know that until one gets raised.

wetpaws 2y ago

[dead]