n-layer using try catch - exception

Question

I'm working on an n-tier application, and doing try/catch only in my presentation layer. If an error occurs in the data layer or business layer, this error is captured by the try/catch in my presentation layer. Is this good, or should I work with try catch in every method of each layer?

Answer 1

In general, it is better to catch an exception as close to where it happens to allow for your code to potentially do something to fix/adapt/react to the issue. What this "do something" is depends upon the circumstance. For instance if you have a service layer call that fails, you may want to retry the call, because the service may have been too busy; whereas if your stored procedure is broken, then it does not matter how many times you retry, it will be broken until the logic is corrected in the database.
If all you want to do is log errors, then catching an error as close to where it happens is less useful.
Every project I have ever worked on had try-catch blocks in every layer of the application.
A corollary to try-catch is the concept of Fail Fast, which generally says that debugging productivity increases when a system immediately fails instead of failing slowly (read: after hours, days, weeks, months or even years of operation).
A good example of failing fast in the .NET Framework is the usage of Convert.ToInt32() versus a straight up cast using (int), like this:
int? settingValue = Convert.ToInt32(SomeSettingString);
if(settingValue == null)
{
// Do something here
}
else
{
// Do something else here
}
If SomeSettingString can be converted to an int, then the value is set to and Do something else logic is executed. Suppose a year from now, the setting changes and null is returned, because the conversion fails, now all of a sudden the Do something here logic executes and it is a debugging adventure to figure out that this condition happens, if you can find out at all. Most issues like this seem to only happen in PRODUCTION and not DEV.
Now let's look at the same thing, but by failing fast, like this:
try
{
int settingValue = (int)SomeSettingString;
}
catch(Exception ex)
{
// Fail fast and throw exception
throw new Exception("Fail fast");
}
Now the exception happens immediately when the setting string causes a conversion to int failure.
Note: Beware that failing fast can be sabotaged by empty catch blocks that "eat" exceptions. try blocks with empty catch blocks should be avoided, because they invariably lead to the "eaten" exception scenario.
Don't do this:
try
{
// Exception waiting to happen here
}
catch(Exception ex)
{
// Catch-all, because all exceptions derive from Exception class
// So this will eat exceptions and pretend like they never happened
}

Answer 2

Here's what you want to avoid at any level: a bunch of methods that all look like this:
void method()
{
try
{
// some code here that may potentially throw an exception
}
catch ( /* anything here */)
{
// code right here to handle that exception
}
}
If that's what you're doing, you may just as well go back to VB's old On Error Goto system, because you haven't gained anything. Exceptions provide two major advantages for error handling: the ability to easily handle different types of errors in different ways, and the ability for errors to be caught further up in the program's call stack. It's the second advantage that you're asking about here.
So we see that you do want to allow exceptions to "bubble up" to higher layers, as it's a big part of why we have exceptions at all... but do you always want to handle them at the presentation layer? No, we can do better. Sometimes, there may be business rules about how to respond to certain exceptions from the data layer. Sometimes, the data layer itself may be able to handle and recover from an exception without alerting the layer above it.
On the other hand, an advantage of exceptions is that it can leave you to write simpler code in the lowers layers, with fewer breaks from the normal flow of program execution for error handling code. That comes at the price of instead placing more of try/catch in the presentation tier. Again, this doesn't mean that the presentation tier is the only place to handle them, but this is the place to make the effort to ensure they don't get past your presentation layer un-caught. If you can't handle them anywhere else, do have a way to catch them in the presentation layer and show them to the user in a friendly way. It's also a good idea to use the the same mechanism to log or report your exceptions, so you can get good metrics on where you applications fails, and then use that information to make your application better.
When you do get to the point that you're inside an last-ditch exception handler, you may also want to consider terminating the application. If you really have unexpected things going on, such that unhandled exceptions make it through the presentation tier, there's a valid school of thought that suggests it may not be a good idea to continue running the program. But even in this case, you'll want to catch and try to report the exception, and then crash as gracefully as possible.