On Wednesday 08 October 2008 7:17:59 pm Christian Schneider wrote:
> I would propose to add the following to UncheckedException and
> corresponding "super" calls to all exceptions.
>
>     public UncheckedException(String code, ResourceBundle bundle,
> Object...params) {
>         this(new Message(code, bundle, params));
>     }
>
>     public UncheckedException(String code, Throwable t, ResourceBundle
> bundle, Object...params) {
>         this(new Message(code, bundle, params), t);
>     }
>
> To use these you could do the following at the start of the class:
>     static final Logger LOG =
> LogUtils.getL7dLogger(JMSConfigFeature.class); static final ResourceBundle
> BUNDLE = LOG.getResourceBundle();
>
> and then:
> throw new ConfigurationException("JMSCONFIGFEATURE_ONLY_JMS", BUNDLE);

Works for me.   A convienience constructor like:
public UncheckedException(String code, Logger log, Object...params) {
         this(new Message(code, log.getResourceBundle(), params));
}

might be nice to avoid having extra derivable instance variables, but not 
really important.

> I have checked where the i18n Message is used and it seems only to be
> used for exceptions. So would it perhaps make sense to deprecate it and
> always create exceptions like above?
> Was there a special reason for the introduction of i18n Message?

Probably.   It was originally (like REALLY REALLY long time ago) also used for 
Logging before we settled on j.u.l since most logging kits don't support 
resource bundles.   Thus, we needed that just to log i18n messages.     Once 
we settled on j.u.l, it probably should have been changed.

> Any opinions?

Go for it.   :-)

Dan


>
> Greetings
>
> Christian
>
> Benson Margulies schrieb:
> > I'm +1 to the constructor. I find the new-ing of messages to be a pain.
> >
> > On Tue, Oct 7, 2008 at 5:27 PM, Christian Schneider
> > <[EMAIL PROTECTED]
> >
> >> wrote:



-- 
Daniel Kulp
[EMAIL PROTECTED]
http://dankulp.com/blog

Reply via email to