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
