Question

In a stack trace, the method call at the top is the most recently called method.

When the phrase “handle it higher up” is mentioned, does this mean in the method caller or to call another method in the catch block?

Furthermore, in a multi-tier application with an API I wrote, it seems like the best strategy is to always log an exception and handle it as soon as I can and rethrow so the calling method in the UI can display the error. Is there any other usage scenario for exception rethrowing?

Should actions such as retrying an operation or loading another file by default if a file is locked happen in a catch block? Is exception handling about reporting the error or is it about trying the operation again/trying again with different parameters?

Thanks

Answer 1

1. Higher up means lower in the stack, yes.

2. If you are going to change the way you do the retry — i.e., a strategy that you know WILL work or a collection of strategies from which ONE will work then perhaps you can do it in the catch; however, error codes from functions, or bool’s, are probably better; this is because we are not actually talking about exceptional behaviour.

3. Exception handling is NOT a looping mechanism, no. Retrying again and again is evil inside exceptions.

4. Often you should log exceptions, but that is not the main purpose of exceptions. Exceptions are their as a standard mechanism to recover from exceptional behaviour in a well documented (in code) way. They replaced the goto and longjmp statements in C and C++. Where if something did go wrong you would do absolute jumping to a label somewhere in your code.

5. logging the exception and re-throwing is good, it is accepted convention.

---

Example and Discussion

In your example of locking, you probably should have blocked waiting on the lock to release. Perhaps a spinlock (or waiting for a short, but defined interval) if the lock was not released an exception would be thrown — now in this case, this would be an exception because you wrote the code that locked the file, and you have written your code to release the lock as quickly as possible.

There is a problem here, you may want to wait a bit longer after your exception has been handled, and i’m betting you want to pretend like the exception never occured — i.e., restart where you left of. but the exception mechanism cannot take you back to the place where the original blocking happened. Your solutions are:

1. You can start a new code regression from the exception (as you mentioned above) by trying again (not again and again though 😛 ). But this is a new regression of your code, and that is not right.

2. You can jump to a position where you initially waited. However labels and jumps will make you a pariah in most programming teams. I don’t feel so uneasy about them, but thats me.

3. You can use error codes and defensive programming. This is the cleanest way to go. Your tries will only embody the code you intended to be run, and your exceptions, the exceptional behaviour which you truly do not expect.

code:1

try{...}
catch{alternateStrategy()}

code:2

try
{
   IAmALabel:
   checkFileLock(timeoutVal);
}
Catch
{
   timeoutVal = timeoutVal*2;
   goto IamALabel;
}

Note: the above is potentially an infinite loop, put an upper limit on it if you use it.

code 3:

int tries=3;
while(true)
{
   int ret=CheckFileLock(timeoutVal);
   if(ret==0) // 0 = success, anything else represents a distinct error.
      break;
   tries--;

   if(tries==0)
      throw exception();
}