> >
> >> 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 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.
> 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
