On Wed, Sep 05, 2012 at 08:16:34PM +0200, Luc Maisonobe wrote:
> Le 05/09/2012 19:09, Ole Ersoy a écrit :
> > Hi Gilles,
> >
> > On 09/04/2012 06:48 PM, Gilles Sadowski wrote:
> >> Hello.
> >>
> >> There are ideas that sound good we experiment with them within a limited
> >> framework (like a course on programming, for example); and then become a
> >> nightmare when you find yourself constantly trying to get around them.
> >> I mean that a design idea might look nice, and only when you are long way
> >> into implementing the consequences of that idea, you discover that it was
> >> not such a good one after all.
> >
> > Been there :)
> >
> >>> As a user of commons math I think it would be great if a each exception
> >>> mapped to a "One of a kind problem". So instead of having a
> >>> NegativeIntegerException, which is generic and could be used in a lot
> >>> of places, have SuperDuperOptimizerNegativeIntegerException, which is
> >>> only thrown in one place.
> >>>
> >>> Is this possible?
> >>
> >> Possible, it is. But have you imagined how many different exceptions that
> >> would entail?
> >
> > I really did and thought maybe this is just crazy.
> >
> >> Currently, there are more than 1000 "throw" statements in CM.
> >>
> >> My position is to have a mapping between "exception type" and "problem
> >> kind"; your suggestion looks like a mapping between "exception type" and
> >> "problem location".
> >
> > I would rephrase my suggestion as a mapping between "exception type" and
> > "solution". So if you know the exception type, you immediately know how
> > to provide options to the person responsible for the operation.
> >
> >> Besides the drawback of an enormous increase of the number of classes,
> >> tying
> >> the exception to its place of use is redundant with the information
> >> already
> >> provided in the stack trace.
> >
> > I agree. I really meant "Solution". It seems that we are already at
> > the point where exceptions should provide parameters from the instance
> > that threw the exception for the purpose of UI display, logging, etc.,
> > so if it's going to be that specific, then why not make it so specific
> > that it can only have one possible message and one set of solutions
> > specific to the context.
> >
> >>
> >> [One of the most useful rules in programming is code reuse; it would be a
> >> waste of a programmer's time to create a new exception class just because
> >> it is intended to be thrown from a different place.]
> >
> > I agree.
> >
> > The main reason I threw my 2 cents in is because it seem like the design
> > of the exceptions was getting very complicated with the inclusion of
> > localization, unrolling of diagnostic contexts (Not sure if I said that
> > right...), etc. and there has to be a simpler way.
> >
> > For example it seems like localization should be worried about after you
> > catch the exception and you know what to do with it. I like that
> > localization is part of commons math, but to me it seems that it should
> > be a utility that can be used for message display once an action has
> > been decided upon post catching the exception. Right now it seems that
> > localization has become a constraint on exception design.
>
> Looking at localization after the exception has been caught is possible
> only once you are sure all exceptions are unique (which is the core of
> your proposal). As our use and reuse exceptions everywhere, this is
> simply not possible.
>
I'm not so sure that every exception must have a single use. In fact, it
may be a quite appropriate usage of your request: Assuming that the
"getPatterns" and "getArguments" methods are available, what we do now
(formatting of the exception message) inside the "getMessage" of
"ExceptionContext" can be done after catching the exception:
try {
// Computations that can throw CM exceptions.
} catch (MathRuntimeException e) {
if (allIsLost) {
// Build a localized message.
final List<LocalizedFormats> patterns = e.getContext().getPatterns();
final List<Object[]> args = e.getContext().getArguments;
final String msg = TranslatorService.buildMessage(patterns,
args);
// Rethrow.
throw new UserException(msg);
}
// Handle the exception at this level.
}
[The "TranslatorService" would not be part of CM, but a side project
only depending on a "MessagePattern" enum provided by CM.]
Did I overlook something obvious (e.g. a "nice idea that is not so"...)?
What I find nice (caveat notwithstanding) is that it would take the load of
localization off CM. ["LocalizedFormats" just needs to be a "MessagePattern"
without being "Localizable"]. We'd just keep the formatting of the default
(English) message.
Regards,
Gilles
P.S. This is _not_ a proposal. ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
