Hi,
thanks for your answer.
2011/8/4 Gilles Sadowski <gil...@harfang.homelinux.org>:
> Hello.
>
>> 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.
>> 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)? Also, how do I
document the keys which are actually set by a given method? I quickly searched
the current code, and could not find classes which currently use extensively
this apparently recent functionality. I'll try and browse the mailing list
archive to see what the conclusions of the community were.
> 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
>
>
That's what I was going to suggest...
Best regards,
Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
