On 8/26/11 9:22 AM, Honton, Charles wrote:
> 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".
Yes, +1 to that. We do a decent job of that now with exception
messages in [math], IMO. The feature we are discussing on this
thread provides a means to provide access to additional context
information that may be too large/unwieldy to include in exception
messages.
Phil
>
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
