commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Honton, Charles" <>
Subject Re: [math] Consistent use of ExceptionContext [was "using the ExceptionContext facility"]
Date Fri, 26 Aug 2011 16:22:04 GMT
I recommend reviewing Chapter 9 "Exceptions" of Joshua Bloch's "Effective
Java".  In particular, look at Item 63, "Include Failure-Capture
Information in Detail Messages".


On 8/26/11 8:59 AM, "Phil Steitz" <> wrote:

>On 8/25/11 11:15 PM, S├ębastien Brisard wrote:
>> Hi,
>>> One thing that I think we all agree on; however, is that we should not
>>> designing exceptions or APIs that throw exceptions with the intent that
>>> applications catching exceptions should parse the messages or search
>>> the message content for specific strings.
>> I do apologize, I am not sure I fully understand. Please let me try
>> again. I agree, parsing e.getMessage() would be horrible, but that was
>> not what I had in mind.
>> Let's say that a NonPositiveDefiniteLinearOperatorException e is
>> raised, and I want to retrieve the operator in question. One way to do
>> it would be to have a getter
>> e.getOffendingLinearOperator()
>> In MATH-581, following the discussion entitled "Implementation of
>> Conjugate Gradient (MATH-581)" (started aug, 4), we finally went for
>> the more flexible
>> e.getContext().getValue("offending operator")
>> The issue then is a proper handling of the key names ("offending
>> operator" in the present case). Should the key names be assigned
>> arbitrarily by the method which throws the exception, or stored (as a
>> constant String) in the exception itself. My point is that in some
>> circumstances, it is possible to have the exception store "typical"
>> keys, which can be consistently used by everyone throwing such an
>> exception, with the further possibility to add supplementary context
>> to this exception, with freely chosen key names.
>> Is it what you understood from my previous message?
>I am sorry, Sebastien, I completely missed your point.  I was
>confusing message keys with context object keys.  I now understand
>what you are getting at.  I agree with Gilles that user code
>catching a contexted exception can just use getKeys to retrieve the
>keys, but that leaves open the question of how the client code is
>supposed to know what it is looking for.  This may be an
>over-simplification, but I would see the following as natural:
>0) key/value pairs that are  "consistently used by everyone throwing
>such an exception" should be named properties of the exception.  So
>in your example of the offending linear operator in
>NonPositiveDefiniteLinearOperatorException, the exception should
>expose a getOffendingOperator method.
>1) key/value pairs that represent optional or context-variable
>properties of an exception *may* have key names defined in the class
>that throws the exception.
>2) Whenever keys are "named" and included in API specification, we
>should ask whether or not specialized exceptions or named properties
>of the exceptions being thrown should be defined (i.e. it is a
>warning sign when these names surface in API documentation).
>Sorry I did not understand your original post and did not comment on
>the earlier discussion.
>> Best regards,
>> S├ębastien
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
>To unsubscribe, e-mail:
>For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message