On Thu, Sep 22, 2011 at 08:58:19AM -0500, Greg Sterijevski wrote: > I agree with your assessment that having almost identical methods is a pain. > However, without doing this I need to return a very complicated set of > information from isMonotone to be able to construct the exception.
Yes, this would be ugly indeed. > As for catching the exception, I was under the impression that CM code never > catches exceptions, you propagate them upwards on the call tree. I think that you refer to not catching user-generated exceptions. Here the example was given that the caller (a CM method) could decide which exception to throw whenever "isMonotone" returns false. My preference is to always throw the same exception (i.e. an instance of "NonMonoton(e/ic/ous)SequenceException"). However if there is a case where the caller would want to throw another one, I'd thought that it would be clearer to catch and rethrow. Well, that's ugly too; in the end, I think we should stick to "NonMonoton(e/ic/ous)SequenceException". :-) > In thinking about this, maybe you are correct. The exception could be > pruned. I am reticent to do this because it looks like exceptions and > exception reporting are sore subjects on for the developers on this > project? Yes. It used to always be "We want all the details". But then there is also the recent example of "NotPositiveDefiniteMatrixException" where the "threshold" is considered too much detail... Regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
