in reply to Enforcing exception catching

First of all, you shouldn't need to wrap all calls to exception throwing functions in a try/catch block. Doing that is not much different that checking return error codes. You should catch exceptions where you can appropriately deal with them, not where they are being thrown. There is no use in catching an exception if you can't do anything useful with it. But to not catch an exception when you can deal with it (and possibly save the program from die-ing) is a design-time error not a compile/run-time error.

I agree too with adrianh, you probably need some static code analysis, and then have a talk about exceptions with all your developers to agree upon a method of usage. Consistent usage/paradigms is very important among groups of developers IMHO.

Secondly, If your program is throwing uncaught exceptions and die-ing, then wrap the main entry point in a try block. This will allow you to at least catch these exceptions and print out a stack trace before your program dies. Of course this may not be the best place to handle your exceptions, but at the very least you can do something rather than just letting things die.

Of course I am speak of Perl, not Java (which IMHO has got alot of language design problems). If you want a non-Perl reference to how to handle exceptions, don't look at Java instead look at a language like Ada. Java was made for web-applets, Ada was made by the U.S. Dept. of Defense for missle guidance systems (where reliability and smart error handling is key).

-stvn

Replies are listed 'Best First'.
Re: Re: Enforcing exception catching
by dmitri (Priest) on Feb 12, 2004 at 16:25 UTC
      Secondly, If your program is throwing uncaught exceptions and die-ing, then wrap the main entry point in a try block. This will allow you to at least catch these exceptions and print out a stack trace before your program dies. Of course this may not be the best place to handle your exceptions, but at the very least you can do something rather than just letting things die.

    The problem is that there are many programs using the libraries and I don't know which ones do not handle exceptions correctly. (Yet, I will be doing an audit). Placing all top-level calls in try{} blocks seems to be fixing symptoms, not the problem.

      Placing all top-level calls in try{} blocks seems to be fixing symptoms, not the problem.

      It does only fix one symptom, but I never meant that to be a fix for the whole problem (sorry if i wasn't clear). IMO if you have code that throws an exception anywhere at all, your top level call should always have a catch block. You should never let an exception kill your program, you should always catch them so that you can clean up resources and such, or at a minimum log the exception and a stack trace.

      Exceptions are a huge improvement over standard return value error checking not just because they allow you to centralize your error handling (sometimes much further up the call chain), but because they (the exception itself) can carry with it valuable information, like stack traces and contextual information from the call site. This kind of info is invaluable when trying to debug an error, and lightyears ahead of the old standard printf debugging technique.

      -stvn