3 ms·

Exceptions are far far more readable than error code handling. Exceptions allow one to separate error handling from the structure of the "mainline" execution pa

Exceptions are far far more readable than error code handling. Exceptions allow one to separate error handling from the structure of the "mainline" execution path of an algorithm. Weaving if/else statements in and out of the mainline path of an algorithm muddies the intent. Exceptions help with this greatly. Instead of having to comprehend the entirety of the algorithm (when exception handling can sometimes take up 50% or more of the code), you can zero in on the most common execution path. Then understand the degenerate cases in turn. The fewer branches your brain has to process in any given moment is a boon for readability. Yes, exceptions are just fancy goto's--but that is a good thing! Goto's when used sparingly can greatly increase the readability of exception handling code. Exceptions simply create a language level abstraction for this functionality.

beagle3 14y ago
> Yes, exceptions are just fancy goto's--but that is a good thing! Goto's when used sparingly can greatly increase the readability of exception handling code. Exceptions simply create a language level abstraction for this functionality. That is entirely incorrect, except in the odd case of Sinclair ZX Spectrum Basic, which is the only programming language that I"m aware of that allowed you to do "LET a=10: GOTO a" (all other languages with goto require a label; GCC has an extension for "indirect goto" and "label address" that is somewhat similar, although it restricts you to staying within the same function scope). If anything, it's a fancy "longjmp", that also calls destructors along the way. The big difference, and it is HUGE, is that when you do a "goto", you know where you the next instruction is coming from. When you throw an exception, you do not know which instruction will execute next from looking at the throw site (and in fact, you may need to conceptually inspect an unbounded number of stack frames to tell; which is different from longjmp or expression goto which only require you to examine one memory location). > Exceptions allow one to separate error handling from the structure of the "mainline" execution path of an algorithm In theory. In practice, they essentially guarantee that the error handling is not properly tested, and often useless except in the case of "everyday expected errors", which are not really exceptional, but rather quite frequent.
- hackinthebochs 14y ago
  You took my comparison with goto entirely too literal. The point was more about code organization rather than implementation details. This should have been clear from the context. >In practice, they essentially guarantee that the error handling is not properly tested, and often useless except in the case of "everyday expected errors", which are not really exceptional, but rather quite frequent. This hasn't been my experience.

beagle3 14y ago

> Yes, exceptions are just fancy goto's--but that is a good thing! Goto's when used sparingly can greatly increase the readability of exception handling code. Exceptions simply create a language level abstraction for this functionality. That is entirely incorrect, except in the odd case of Sinclair ZX Spectrum Basic, which is the only programming language that I"m aware of that allowed you to do "LET a=10: GOTO a" (all other languages with goto require a label; GCC has an extension for "indirect goto" and "label address" that is somewhat similar, although it restricts you to staying within the same function scope). If anything, it's a fancy "longjmp", that also calls destructors along the way. The big difference, and it is HUGE, is that when you do a "goto", you know where you the next instruction is coming from. When you throw an exception, you do not know which instruction will execute next from looking at the throw site (and in fact, you may need to conceptually inspect an unbounded number of stack frames to tell; which is different from longjmp or expression goto which only require you to examine one memory location). > Exceptions allow one to separate error handling from the structure of the "mainline" execution path of an algorithm In theory. In practice, they essentially guarantee that the error handling is not properly tested, and often useless except in the case of "everyday expected errors", which are not really exceptional, but rather quite frequent.

hackinthebochs 14y ago
You took my comparison with goto entirely too literal. The point was more about code organization rather than implementation details. This should have been clear from the context. >In practice, they essentially guarantee that the error handling is not properly tested, and often useless except in the case of "everyday expected errors", which are not really exceptional, but rather quite frequent. This hasn't been my experience.