Hi Gilles,
Gilles Sadowski wrote:
> Hello.
>
>> > [...]
>> >
>> > Do I understand correctly that, if we go down that road, there would
>> > only be a single exception (every failure will raise the same
>> > exception)?
>>
>> No, not at all, but your exceptions would provide all the same mechanism
>> to add valuable information up the stack. Have a look at the
>> implementation of ContextException and ContextRuntimeException. It's
>> quite hollow, the real code is in DefaultExceptionContext i.e. you could
>> easily create also a IllegalArgumentContectException derived from
>> IllegalArgumentException. And since the ExceptionContext is only an
>> interface you might even replace ther DefaultExceptionContext with
>> something like LOcalizedExceptionContext that has additional language
>> support.
>>
>> > If the aim is only for printing the whole context, it is indeed very
>> > flexible (adding a lot of info is easy). But if the caller wants to
>> > trap and act on a particular condition (a part of the context), isn't
>> > it more difficult than catching a specific exception?
>>
>> As I said, keep the hierarchy, but you might be able to trim it down more
>> easily, because you don't have to invent a new one simply because you
>> want to provide an additional information.
>
> Ah, maybe that I see a use-case in CM: the 3 exceptions
> "DimensionMismatch", "MultiDimensionMismatchException" and
> "MatrixDimensionMismatch" might be trimmed to a single one.
> However, the other problem which I'm still suspecting is that ther
> wouldn't be specific accessors anymore like we have now in
> "MatrixDimensionMismatch":
> getWrongRowDimension()
> getExpectedRowDimension()
> getWrongColumnDimension()
> getExpectedColumnDimension()
No, but you would have the keys "WrongRowDimension", "ExpectedRowDimension",
"WrongColumnDimension", "ExpectedColumnDimension". The keys can be defined
as constants in the appropriate algorithms and you would have to document,
where the information ios set when the exception is thrown:
/**
* @throws MathException if dimensions is wrong. Possible values for {@link
#ERR_WRONG_ROW_DIMENSION}, {@link #ERR_EXPECTED_ROW_DIMENSION} ...
*/
Note, that you can use the same constants for interpolation in localized
strings:
MessageFormat.format("The row dimension {0} differs from {1}.",
ex.getValue(ERR_WRONG_ROW_DIMENSION),
ex.getValue(ERR_EXPECTED_ROW_DIMENSION));
I agree that this is less strict than the direct accessors, but does it make
sense to go that far in exceptional code? Using predefined constants is not
that bad, because the caller normally knows in which context he called a
special algorithm. A user from the next higher abstraction level is anyway
no longer interested in the individual values and reasons, he might simply
rethrow a different RuntimeException stating that the algorithm failed in
general.
Cheers,
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
