My philosophy on this is that whatever exceptions we define should be "close" to the components that throw them -- e.g. ConvergenceException. I do not like the idea of a generic "MathException." As much as possible, I think that we should rely on the built-ins (including the extensions recently added to lang). Regarding ConvergenceException, I am on the fence for inclusion in the initial release, though I see something like this as eventually inevitable. Correct me if I am wrong, but the only place that this is used now is in the dist package and we could either just throw a RuntimeException directly there or return NaN. I do see the semantic value of ConvergenceException, however.
There are several approaches to design a concept for exceptions, all of which have pros and cons. I personally would suggest to avoid returning NaNs and throwing RuntimeExceptions whereever possible and use a package specific hierarchy of declared exceptions instead.
J.Pietschmann
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
