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".
Chas
On 8/26/11 8:59 AM, "Phil Steitz" <phil.ste...@gmail.com> 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
>>>be
>>> 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.
>
>Phil
>> Best regards,
>> Sébastien
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>For additional commands, e-mail: dev-h...@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
