The right time to handle all exceptions

Question

I've done a few projects so far, and i've noticed that every single one i've written entirely without any exception handling, then at the end I do a lot of tests and handle them all.

is it right? i get thousands of exceptions while testing (which I fix right away) that if i've handled it i wouldn't see exactly where it is(when not using breakpoints or displaying it anywhere.. but it doesn't seem as practical) So I fix issues by checking any exceptions, then in the end I handle them anyway for any possible one that might have escaped (of course).

What about you? when do you guys take care of exceptions ?

Answer 1

I would say that this is backwards (but common).

You might want to look into test driven development, and test first design

Hint: think of a behavior, write code to test for it, add it to your application.

Answer 2

Personally, I always define a global unhandled exception manager appropriate to the application type and have that log and email exceptions to my dev team. During QA, we'll then start to add specific exception management to routines that have predictable (and recoverable) issues. In every case possible, we add defensive programming code so that exceptions don't happen at all. (There's no need to trap an exception if you can test before you try code that could fail.)

My apps tend to end up with lots of defensive code (which should be built in from the start) and only some specific exception handling.

Answer 3

I prefer test-driven development. If there is an expected error condition, then test for it. If an unexpected error crops up, make a test for it, then fix it.

Answer 4

I would definitely consider the exceptions thrown as you develop each interface and module.

That way you can test that they're reliably thrown (when you expect and not when you don't). Components consuming these components can then be written to be aware of these exceptions and handle (or not as they require).

It seems to me that you're ignoring some functionality of the components you're developing. I'll virtually always test for both correct functionality and the exceptional circumstances, to cover as many scenarios as I can as early as I can.

Answer 5

The answer to this one is a very clear "it depends".

You need to look at the specific situation; is an exception being thrown in a specific piece of code where it's possible to recover or handle the "exceptional" situation resulting in the exception being thrown? In that case, yes, catch the exception and deal with it at that level.

On the other hand, are you talking about non-recoverable errors? Then sure, catch them at a more global level, or possibly not at all (ie if there's nothing you can do about the exception, why are you catching it?)

Answer 6

The rule for where to catch exceptions usually is: wherever is the place you can meaningfully handle them.

Answer 7

Sometimes it depends upon the technology or target platform. I usually prefer an exception handling layer that takes care of all the exceptions. Each and every block of code is inside a try catch block.

Bottom line is that no exception should get caught by the OS or any other entity outside the program or code.

Answer 8

The beauty of exceptions compared to say returning error codes from API's is that you don't have to check for exceptions at every layer in your code. You can catch specific exceptions to determine specific error conditions and perhaps handle the error or rethrow a more appropriate exception. You also have to catch exceptions at a high level in your application to avoid unhandled exceptions.

One thing to note is that generally the user of the exception is the developer and not the end-user. The later normally doesn't appreciate the technical details of exceptions.

Answer 9

The most common thing I've seen is developers making a conscious choice as to what level to handle exceptions, and allow them to be thrown. Typically it will be at the level of a worker thread, or a high level of business logic. Allow the exceptions to happen, and have a blanket method of handling / logging them and protecting the user from them.

Timing is the only difference between what typically happens and what you do. Plan for it in your applications from the beginning, and do exception handling at high levels.

Fixing specific exceptions is done via your method of fix it when it's a problem. Sometimes a library I use will needlessly use exceptions to communicate information, and I will add specialized exception handling around all calls to that library. Often I will do this in a wrapper class that hides the implementation and exception handling from the rest of my application.