Jerry Jalenak wrote:
Erik, David, and Mike -
Thanks for the replies - interesting to note that all three of you suggested basically the same answer, that of using the exception mechanism.
I think it's just that one of the cool things about Java over PHP or C is that we have exceptions, and we don't have to test return values -- we can just write code that assumes that an exception was not thrown, but if one -is- thrown, we can catch it and deal with it.
(Within limits -- obviously it's not just as simple as assuming that no exceptions are thrown....)
When implementing this, do you code individual, specific exception handlers (i.e. InvalidUserException, etc), or do you have a generic handler that you can pass a 'cause' back through?
It really all depends on the context, but what I have done is I have a set of exceptions that I use exclusively within the domain layer of the application. These are thrown or caught as appropriate, for instance, a SQLException is caught by my JDBC-using code, but when I rethrow this from my JDBC data access object business delegate I wrap it inside of a home-brewed PersistenceException. This way, if I switch to use a EJB data access object business delegate, I can catch the RemoteExceptions (or whatever EJB-specific exceptions are thrown) and wrap -them- into a PersistenceException.
The advantage of this is that the facade-side of my data access objects don't have to know whether it's a SQLException or a RemoteException that caused the problem, it just catches PersistenceException and does what it needs to do. Sometimes I can end the exception-handling right here by performing whatever steps are needed to fix the problems. Other times, the facade (which is the outermost level of my domain logic right now) needs to report back to my Struts Action that there has been an exception. I don't have my code return a special return value if there has been a problem, rather I rethrow the PersistenceException wrapped inside of a DomainException. My Struts code can then handle only DomainExceptions without needing to know the details. But if I did need to know the details of the DomainException (such as to provide a more useful error message to the user as to what went wrong, or to email myself some info), I can unwrap the DomainException and get at the PersistenceException, or something.
This is a simplification and not actually exactly how I've implemented it, but it shows two things -- 1, you can avoid messy situations with a long string of conditionals (or switch statements, which I don't care for) that test for return values by throwing a meaningful exception and putting the appropriate exception-handling code in the catch statement. 2, you don't need to expose all of your exceptions to every layer of your application -- some of your custom exceptions are exclusively used in your domain/model layer, others can be seen by the controller and can affect how it renders the view. Doing this helps keep your controller and model from being tightly coupled.
Regards,
Erik
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
