2011/8/4 Gilles Sadowski <gil...@harfang.homelinux.org>:
>> >
>> >> I'm OK to define a new exception. From your PS, I understand that I
should
>> >> wait until what I've already submitted (MATH-581-06.zip) has been
>> committed
>> >> until I submit a patch containing the new exception. Is that right?
>> >
>> > I would have thought the other way around: First commit the exception
than
>> > commit the code that use it (i.e. a new patch). That will avoid changing
>> > that code afterwards just to use the new exception.
>> >
>>
>> Sounds great! I'll do that, and post a new bunch of files. I'm just
starting
>> to worry about the large list of files attached to the JIRA ticket, while
>> almost none of them is really useful, since they were subsequently
modified...
>> I understand there is no functionality to remove files, so we just have to
>> live with all those "near-duplicates". Maybe I should add a comment at the
top
>> of ticket, summarizing which files are useful, and which files are not.
>
> On the JIRA page, do you see a "triangle" icon (at the right of the "+" to
> add attachments). If so, when you click on it, do you see a menu with a
> "Manage Attachments" item?, If so, when you click on that item and go to
the
> new page, do you see a "bin" icon at the right end of each file entry?
>
I'm ashamed to say I've been looking for this functionality for quite a
while... Thanks A LOT, I'll do a little bit of cleaning up tonight.
>> >> I don't think it's necessary to open a new JIRA ticket for this, do
you?
>> >
>> > No.
>> >
>> >> Finally, a design issue. I would like the
>> >> NonSquareLinearOperatorException to have an accessor to the actual
>> >> LinearOperator which was the cause of this exception. It seems to me
that
>> >> NonSquareMatrixException does not offer this opportunity, so having the
>> latter
>> >> inherit from the former might be difficult. Should I give up this
>> accessor,
>> >> then? I think it would be a pity. As an example: the constructor of a
>> >> preconditioned iterative solver requires TWO LinearOperators, both of
>> which
>> >> must be square. If an exception is raised, it would be nice (although
not
>> >> absolutely essential, since I can always test a posteriori the size of
>> each
>> >> operator) to know which operator was faulty.
>> >
>> > I'm still wondering whether it is useful to provide access to a
high-level
>> > object (such as "RealLinearOperator" or "RealMatrix") from an exception.
>> > What are you supposed to do with it? Printing cannot be a default
option
>> > since, from what I understand, it could be huge.
>> >
>> > Also, if keeping those data in the exception is useful in some
>> circumtances,
>> > we could use the "ExceptionContext" feature that was recently
implemented.
>> > Code would look like
>> > ---CUT---
>> > /**
>> > * [...]
>> > *
>> > * @throws NonSquareLinearOperatorException when [...].
>> > * The offending operator can be accessed from the exception context
(cf.
>> > * {@link org.apache.commons.math.exception.util.ExceptionContext},
using
>> > * the "operator" key name.
>> > */
>> > public void doSomething(RealLinearOperator op) {
>> > // ...
>> >
>> > if ( /* test */ ) {
>> > final NonSquareLinearOperatorException nslo = new
>> NonSquareLinearOperatorException();
>> > nslo.getContext().setValue("operator", op);
>> > throw nslo;
>> > }
>> >
>> > // ...
>> > }
>> > ---CUT---
>> >
>> > Yes, that's more code to write (but you only do it once), but it makes a
>> > clear separation between not often used data, and default information
that
>> > will usually end up printed on the console.
>> >
>>
>> I like that, and will change the code accordingly. Is there an agreed
policy
>> for the naming of the keys (upper/lower case, and so on)?
>
> No.
> I'd suggest to follow the same convention as for naming classes. We can
> always modify it later if someone has a better idea.
>
The management of the exception messages through String constants and enums is
in my view a very clean thing. Should we do the same for exception context
keys? Have a big enum holding keys? Or should we define these keys as
constant, public fields inside those classes which throw exceptions? Or, are
we happy with inlining the string, just like in your piece of code?
I kind of remember that JAI has the same kind of management through String
keys, but I have never had a look to the code to see how these keys were
managed internally.
>> Also, how do I
>> document the keys which are actually set by a given method?
>
> Cf. my above sample code excerpt. [Except that, with the convention just
> suggested, the key would be "Operator" or "RealLinearOperator".]
>
>> I quickly searched
>> the current code, and could not find classes which currently use
extensively
>> this apparently recent functionality.
>
> There is none; you'd be the first one to use the functionality.
>
>> I'll try and browse the mailing list
>> archive to see what the conclusions of the community were.
>
> There was no dicussion about how or when to use that functionality.
> Originally it was supposed to be a feature offered to users but which would
> not be directly useful inside CM. I think that your code proved that wrong.
> :-)
>
>> > I would thus also propose to remove the "getOffending..." from the
existing
>> > exceptions (and replace them likewise).
>> >
>> >
>
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> 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
