struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Hardy <>
Subject Re: [OT] Exception.getLocalizedMessage()
Date Sun, 23 Dec 2007 13:26:28 GMT
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 

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:
For additional commands, e-mail:

View raw message