Discussion on Exception Handling

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.

I think most errors should be handled with assertions. Establish and document the appropriate preconditions for every routine, and make sure they are never violated. With these assumptions, you can obtain the maximum performance by cutting out the error checking in the non debug version of the executable. Horrible things will happen if the error does occur though, so you have to be careful.

If the verification of the precondition is difficult and easier to do from within the algorithm, then I think return codes are sufficient. It is like turning:


if cool(G) {
  algorithm1(G);
} else {
  algorithm2(G);
}

into:


if(!algorithm1(G)) {
  algorithm2(G);
}

where algorithm1 becomes:


bool algorithm1(G) {
  ...
  ...
  if(it became evident that G is uncool) {
    clean up stuff.
    return false;
  }
  ...
  ...
  return true;
}

Sometimes that can be more efficient than using the cool function to inspect G and determine which algorithm is appropriate. But if you know in advance that algorithm1 should work, then you should give yourself the ability to cull the error checking somehow.

One alternative to exceptions is to pass in an error handler object. I believe this is similar to conditions in lisp, but it has been a long time since I've looked at those.