hi gary,
thanks for the thoughts. You're right, AOP would do it, but I also have a
dislike of AOP and would want to use it for this unless I was convinced it was
worth leveraging getLocalizedMessage().
I'm with you on the idea of putting the localization key into the exception, but
I'm not too keen on the idea of a LocalizedMessageResolverForExceptions in the
business model. I prefer the idea of providing the Locale and the ResourceBundle
via some static ThreadLocals - I guess they could sit on the app's base
Exception, and the front-end would initialize them via a filter or an
interceptor so that any exception thrown can see them.
Saying that though, is there any point? Why bend over backwards like that? I
searched the web for references to getLocalizedMessage() usage, and of course
found a hundred thousand online javadocs for every java app under the sun
quoting "inherited from Throwable", but none of the ones I looked at implemented
it.
Are there any frameworks out there that leverage getLocalizedMessage? For
instance EJBs, webservices, JSF, Swing, SWT?
Gary Affonso on 23/12/07 05:43, wrote:
A agree that you're going to have to bind something to the Exception in
order to do I18N resolution. And I agree that creating that binding sucks.
If you don't want to ditch getLocalizedMessage you could AOP it. Have
your getLocalizedMessage() method wrapped with some advice that swaps in
the localized version of the message. Spring makes that pretty easy,
and it makes it easy to bind dependencies to the advice.
At least I think Spring makes that easy, I've never applied advice to an
Exception. Spring's AOP is a bit watered down from something like
AspectJ, it may be if you want to do something like advise methods
within Exceptions you'll have to drag out the AOP big-guns.
But jeez, AOP? I try to use AOP pretty sparingly. While it can make
certain hard things really easy (stuff that clearly cross-cuts, and
cross-cuts a lot) it also can make code way, way more obscure.
You could also just return your custom exception classes with no
localized messages at all. And then have a class...
LocalizedMessageResolverForExceptions
... that knew how to accept each of your custom exceptions and map it to
a localized message. At least that way all the message-lookup
dependencies are in your Message resolver class.
That assumes, of course, that you're willing to create a fairly
fine-grained custom Exception hierarchy (one Exception per message so
that the MessageResolver knows what message to lookup).
The other way to go would be to create a fairly course-grained hierarchy
but embed within each instantiated Exception class some key that could
be used by your MessageResolver later down the road (in your action, in
your view, etc). So your Exceptions would implement something like...
String getMessageKey()
And then in your view or action you'd pass that key to your
LocalizedMessageResolver and it would return the localized message.
Going that way also makes your LocalizedMessageResolver Exception
non-specific, good if you want to lookup more than just
exception-related messages. Anything that could return a message key
would work with it.
The downside to the key-idea (as opposed to the fine-grained Exceptions)
is that you lose some type safety (you can indicate an incorrectly
spelled key and you wouldn't know it). Sure would be nice if all the
keys were static constants in the MessageResolver class but then you're
back to having a dependency in your Exceptions.
Obviously some give or takes but maybe that gives you some ideas. I'm
going to be tackling our own message service soon, this was helpful to
think through. Timely question (for me)! :-)
- Gary
Adam Hardy wrote:
I came across a conundrum while implementing the S2 exception handling
that we were discussing in another thread.
As the title suggests, I'm interested in
Exception.getLocalizedMessage() but have a seemingly intractable
problem with it.
Exception.getLocalizedMessage() returns by default the message in
getMessage() but is put there by Sun and the Java creators as a useful
method that we coders can override in our Exception child classes with
our own method that localizes the exception message.
The problem is, my exceptions mostly live in my business model module.
However, to localize the exception message, the exception needs access
to a Resource bundle which are all front-end artifacts that I don't
want in my business model module.
Also I don't want a dependency from my business model onto the front-end.
And of course, I can't pass in parameters when calling
getLocalizedMessage().
So what's the score here? Is getLocalizedMessage() dead in the water,
or is there another way that's not overcomplicated?
Is there anybody actually implementing getLocalizedMessage() on their
exceptions?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
