[EMAIL PROTECTED] wrote:
Brett Connor <[EMAIL PROTECTED]> wrote on 09/09/2004 12:22:39 PM:
<big snip>
Taking a step back though, the locale is required for presentation only
(in this example), it belongs in the view rather than any business
components. It is not the job of the business layer to be deciding how
to present things. It has to make the information available that any
presentation components may need - in this case the exception type, any
further detail such as error codes, message parameters etc. Things like
the call stack are usually not presented to users, they require very
activity / use case related information. In this respect using
getMessage() from chained system exceptions such as IOException doesn't
lead to the most user friendly application. Your application knows what
it was trying to do when it caught FileNotFoundException, this can be
presented in a much nicer way to the user.
This is what I'm trying to do. Give user friendly messages to be displayed
on an exception reporting screen. In order to put a localized message in
the exception tho' I need the locale. Is it better to just keep a key of
the message in the exception as a constant, populate the exception with
parameters and then form the message in the Action when the exception is
ultimately caught?
Yep. The error code in whatever form it is in (depending on your company standards and convesions) can be used to directly determine what went wrong, technically, in the same way that we all recognize HTTP 404, but no text is present. Are you familiar with Oracle? That's a nice example to use. Every Oracle product has a namespace (actually it's a fairly pervasive product code). Every possible message / error condition has a code within that namespace, and can be looked up in one of the reams of manuals or references. For example ORA-1403 (IIRC) means "no rows found matching the criteria" - coming from the database. PLS-1403 will mean something quite different, ORA-22146 will be different again, etc. The exception in this case would contain "ORA" and 22146 - comprising between them a key, and perhaps also some parameters relating to the message or error. It will _never_ contain message text. The action or any other appropriate presentation layer builds whatever will be shown to the user. Typically for me this is handled by common code called by actions, rich clients etc, ie not tied to a web app.
Note that at this presentation layer I would not expect to be dealing with Java exceptions in this way, by now they're either related to the use case in some way that the user will understand, or they're something seriously wrong in the system. This is where it becomes tricky to keep on the straight and narrow I find, I want the user meaningful context to be available in or from the exception, the presention code reporting the exception should not have to try and guess what the user was doing from their POV when things went wrong. Messages like "XML parse error: element <frog> missing required attribute X" doesn't mean anything to me - I thought I was ordering a book - what the hell is a frog doing there?! Even a call stack is not going to help me at this point. This is a constantly evolving area for me, each project I refine things a little further based on what didn't work quite as I'd hoped, and try to consistenly use the scheme, so that every exception thrown out of the business layer has all of the context required for a dumb but pretty presentation.
Brett Connor
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
