I am coding in a multitier architecture in Java, and I perform a query to a web service.
Is it better form for the errors returned by the service be handled in the data access layer or in the business layer?
For example, the service records a response something like this:
<?xml version="1.0" encoding="UTF-8"?>
<ReturnCode>[integer]</ReturnCode>
<ReturnMessage>[String correponding to ReturnCode]</ReturnMessage>
<UpdateTimestamp>[dateTime - only present if ReturnCode == 0]</UpdateTimestamp>
<UpdateUser>[string - only present if ReturnCode == 0]</UpdateUser>
</xml>
If I handled the errors in the data access layer, my Java code would like something like this: Error logic in DAO. (notice the data type doesn’t have returnCode or returnMessage fields)
If I handled the errors in the business layer, the code would look like this: Error logic in BO. (notice the data type has returnCode and returnMessage fields)
I’d say that Fail-fast approach is also applicable in your situation. That is, you should handle the error as close to its source as you can. If you do this webservice call from the business layer and then want to save results of that call in the database, then you should handle error in the business layer. If it’s done as a part of data access layer, handle it there.
The underlying layers — service / DAO in your parlance — should just throw exceptions when they hit them. Let the UI layer (web services in this scenario) handle how to deal with it for the client.
The main issue is if you try and handle it down low then your service / dao need to have more intimate knowlege of the top end of the stack then they really should leading to a whole host of other design issues. Being able to fire and forget exceptions like this is what makes them much more powerful than other error management techniques.