I write a three tiers web application. DAL BLL and web Presentation Layer,every tier has methods , so the question is where should I catch exception( using try catch),in web?BLL?or DAL? and why? thank you.
4 Answers
Its better to catch exception at database layer and throw it to business layer and than from throw from business layer to presentation layer.
I rethrow exception by using throw keyword and do not display exception to user just show the error message and log exception using LOG4NET or in the file which way you find easy for you.
You can check this post how to throw exception without hiding the detail : Handle Exception Carefully

- 175,020
- 35
- 237
- 263
-
could you give a example more detail ,thanks .may be a blog is ok.:) – SleeplessKnight Aug 11 '11 at 07:48
An Exception is part of the interface of any method.
int doSomeThing( ... ) throws Some exceptions
the exceptions may be explicit, as in Java's Checked Exceptions, or implicit. None the less the caller must anticipate exceptions and decide what to do - sometimes a method may decide just to allow the exception to propogate, exceptions from things you call become part of your formal interface.
My approach:
- Each layer should encapsulate its implementation details; in particular end-users should not see technical error messages
- Robust applications must log error symptoms to allow problem diagnosis
Hence, in Web/Presentation tier, we catch all exceptions and display friendly messages to the user. There tend to be a small number of common scenarios:
- The business logic layer temporarily can't service your request (eg. DB is down), I include in this heading the unexpected, null pointers and so on, they are caused by coding errors, but they are remediated down in the business layer
- You, mr customer, are not authorised to do that
- Your request is invalid, it violates some business logic rule (no you can't specify a bull-dozer attachment for your new Rolls Royce)
I find that the UI sometimes displays the error information differently in those cases, and hence I like to distinguish them. This leads me to design my Business Logic interfaces to throw corresponding Exceptions: TransientException, AuthorisationException, InvalidRequestException.
The InvalidRequestException tends to have useful payload to help the UI format a useful response.
The TransientException can include technical information (like DB XXX has problenm YYY) not for display to the user, but as an aid to diagnosis in a distributed system.
The business logic layer is responsible for catching the myriad problems from lower layers and producing the exceptions for the UI.
The Data access layer should follow the principle of First Failure Data Capture: catch problems log the error in detail and throw some suitable exception.

- 54,992
- 14
- 74
- 117
Dont use try catch in all your methods unless you are sure to handle the error.You can probably use catch in DAL ,log the exception and throw it up the layer.
see this post Exception handling

- 1
- 1

- 2,379
- 2
- 21
- 36
The link given by Pranay Rana, describes the correct way to propagate the exceptions from layers however, it is not necessary to warp methods in try catch in underlying layers( DAL, BAL) until unless you need to take some action against exception.
Wrap the methods in try catch when some code segment is mandatory to be executed before exiting the method e.g cleaning up SQL connection/resources before exit. Warp your methods like
Try
{
}
Catch
{
throw;
}
finally
{
//Mandatory code segment
}
Make sure to wrap the calls (in UI or any other layer) in try catch. The exceptions will be caught at the calling point, even there is the methods are not wrapped in try catch in underlying layers.

- 2,588
- 2
- 26
- 29