4

If I have code like this:

void a() { try { b(); } catch (MyException) { // Handle any problems that occurred in b(c(d())) } } void b() { c(); // Do something else } void c() { d(); // Do something else } void d() { // Do something, throw a MyException if it fails }

Assuming no cleanup is necessary at any point, is it best to put a try{}catch{throw;} around the call to d() in c() and the call to c() in b() or is it considered OK to let the exception from d() bubble up to a() "naturally" without any intervening try/catch blocks?

I suppose the extra try/catch block act as a sort of "documentation" but they seem superfluous so I'm just wondering what other people would consider the best way.

Sorry if this is all a bit too basic, I'm trying to get my head around exceptions but I don't seem to have a good feel for them yet.

Improve this question
1

4 Answers 4

Reset to default
13

Let it propagate until you can handle it. If you can't handle it, there's no point catching it. So the question is, can you effectively handle the exception inside the c() method?

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

3

Basically, no. This is not the suggested way to handle these situations.

You should catch exceptions if and only if you can either handle them and do something appropriate with them or to provide more info to the callers higher in the call stack (by encapsulating it in a more generic exception). If you can't do it, you should let the exception bubble up in the call stack until someone can handle it appropriately.

Improve this answer

Comments

3

The great advantage of exceptions is that you can deal with problems where you can do womething about them, rather than directly in the function where e.g. a missing file is detected, or in the function's caller, or its caller, &c.

However, exceptions also have to be handled somewhere along the chain. Where these points occur depend on the framework you are using, and what its exception management consists of. The key question is: what are your points of entry where allowing an exception to escape uncaught would have bad effects? Typical examples include

  1. Event processing code in interactive UI applications (which at least in WinForms and ASP.NET can be caught en masse by providing exception event handlers).
  2. Integration points where you respond to external messages (e.g. picking up messages from a queue, processing a file, listening on a named pipe, implementing a WCF service).
  3. Timer events where you do background processing.
  4. Thread start methods.

Sometimes, you also want to catch a low-level general technical error and rethrow it as a more domain-specific exception. This typically done in well-designed libraries to shield users from its internal implementation details. In an enterprise application, you might want to catch certain SqlExceptions and rethrow them as application-specific exceptions (e.g. YourApp.UnknownCustomer), in order to deal with them at higher levels of logic.

My advice would be: deal with problems at the highest level possible, but ensure that the exception catchers up there have reasonable exceptions to work with. And, by the way, unless you hate your users, don't display the exception and its stack trace to them! ;-)

Improve this answer

Comments

0

I'd say, it depends on what you want to do with the information.

I always try to catch problems as close to the source as possible - why run all the way back with the problem, instead of trying to deal with it where it happens? For readability and understanding of the code, I also believe in try/catch as close to the source of the problem as possible.

If you're writing the program for yourself, and noone else will ever touch it, do whatever works best for you and the code.

Improve this answer

Comments