The problem I have with that is, that with most applications I have been involved with, exceptions that get passed all the way up (meaning they are not caught somewhere in between by some business class that does some reactive operation) all result in fundamentally same consequences. Transaction gets rolled back, error page is shown, and an error message is shown to the user. The only difference between each type of exception is the error message shown.
For this purpose only, for differentiating between different messages to user, it feels silly to implement horders of different exception classes. In a big project you get lots and lots of those, and I don't really see the benefits that they bring. What I have usually done, is implement one generic exception class, and provide exception message with constructor. As in (in some business class, ie. User)
> 1)
> if (alreadyExists(email)) {
> throw new MyAppException("E-mail address already exists");
_if_ the exception results in some other consequence than error message being shown
(for example,
EmailService.do() {
try {
createUser()
} catch (EmailExistsException e) {
email = createRandomEmail();
createUser()
} - or something like that
)
then I have created a special exception class for that. Those cases are usually a small minority, something like 5% of cases. You mentioned the DAOException, and other similar ones. Those I have found to be useful. But exceptions that result from breaking some business logic rule / invariant - usually there's no sense in defining specific exceptions for those. In my opinion.
Of course, you create a coupling between presentation layer and business classes with that. It can be avoided with some techniques (like throw new MyAppException(Exceptions.get(Exceptions.EMAIL_EXISTS))).
I am fully aware that this is probably not the "accepted" way of doing this. All advice seems to say to create specific exception classes for your applications exceptions. I have just never really understood what benefit it _really_ brings. It would be nice to "see the light" though, so I would not have to be such a heretic anymore.... :)
From: "Jim Barrows" <[EMAIL PROTECTED]> Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Subject: RE: Proper place for validation Date: Wed, 8 Sep 2004 08:52:05 -0700
> -----Original Message----- > From: Janne Mattila [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 08, 2004 3:49 AM > To: [EMAIL PROTECTED] > Subject: RE: Proper place for validation > > > Hmm, not a lot of comments on this. I guess there is a > consensus on the > matter (that, or no-one really gives a damn). > > A quick followup on this; how could I achieve both > > a) decoupling of my business classes from Struts > b) internationalization > > if I validate in my business class? > > 1) > if (alreadyExists(email)) { > throw new MyAppException("E-mail address already exists"); > > achieves a) but not b), and > > 2) > if (alreadyExists(email)) { > throw new MyAppException("errors.email.duplicate");
Simple, you throw EmailAlreadyExists( email), and catch that, or use the exception handling ability of struts to give an appropriate error message to the user. For system level stuff (ie DB is missing etc) you inlcude a cause, but don't necessarily show it to the user.
_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
