You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Adam Hardy <ah...@cyberspaceroad.com> on 2007/12/23 01:34:39 UTC
[OT] Exception.getLocalizedMessage()
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?
regards
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] Exception.getLocalizedMessage()
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] Exception.getLocalizedMessage()
Posted by Gary Affonso <gl...@greywether.com>.
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?
>
> regards
> Adam
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [struts] [OT] Exception.getLocalizedMessage()
Posted by Dale Newfield <Da...@Newfield.org>.
Adam Hardy wrote:
> And of course, I can't pass in parameters when calling
> getLocalizedMessage().
ThreadLocal?
-Dale "Pass through the common block" Newfield
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org