What does /prog/ think of exception handling, as opposed to other methods such as return values or a global error variable/object? Personally, I think that exceptions in languages like C++ and Java have really introduced a much better method of handling errors that is language-independent. It makes your code infinitely more concise and readable, and now your errors actually have meaning beyond 0, "", null, etc.
I'm in my first year of computer programming at a local university, and we're just learning about exceptions now. It was like the world opened up; I couldn't believe how I could have accomplished anything before this, not knowing about exception handling. Never again will I have to use archaic methods of error handling.
Name:
Anonymous2012-01-28 21:42
C++ style exceptions are only a non-local dynamic control transfer mechanism. There is little in the way of recovery possible.
Before a "handler" executes, the stack must be unwound back to the dynamic point where the handler was established. This process discards valuable information, making it impossible to return to the place where the error situation occurred and choose an alternative future execution path (i.e. recover).
Real exception handling means that you keep all information about the program until a decision can be made about how to recover. This means that handlers execute in a new context, prior to unwinding taking place.
PL/I conditions are like this. If a PL/I handler ("on block") returns, then the error code is basically retried (if you do this for something like division by zero, the behavior is undefined).
Lisp conditions are like this. Condition handlers are dynamically registered on the stack, but when they are invoked they are called as closures in a new environment, not in the lexical environment where they are defined.
CPU exceptions are like this. When an exception happens (page fault, division by zero, privileged instruction, ...) a snapshot of the machine state is saved in some exception frame (and perhaps some of the work of recovering the state is up to the handler). This allows the handler to fix up the situation and re-start the program from the very instruction that triggered the fault. For instance, make a not-present page of memory available.
C++ exception handling is just syntactic sugar for longjmp. It is not exception handling, it is exception bailing with cleanup, which is just a notch better than bailing without cleanup.