[EMAIL PROTECTED] wrote: <snip>
I've started using chained exceptions per the suggestion in Struts in Action. I'm also trying to localize the messages. What I'm not sure of is the best way to get the locale down to the lower layers where the chained exception originates.
I haven't passed the session or request objects down in order to keep the
business layer from knowing what's going on in the V & C layers. Instead,
I've passed a User object down that has the locale. What I don't like tho'
is that I've got all these method calls with the User being passed in. Is
there a better way? Is it overkill to keep the session object out of the
business layer when I know this will only be a web app?
In general it is good practice to use abstractions where you can (not at the expense of jumping through more hoops - like everything, if it's useful, helps roduce better code, use it). I would prefer your "User" object (an abstraction I presume) rather than an HTTP session or something more struts specific into the business layer.
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. Anything more serious IMHO can be logged as is, with a general "badness happened - see the boss" type message, which in someones web browser I believe is as useful to my mum as UnsupportedOperationException. One nicety I like in these cases is to include a reference to a log file or system error report or something that people can use in an error report, but I'm wandering a bit of topic here. My 2c.
Brett Connor
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
