commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <p...@steitz.com>
Subject Re: [math] proposed ordering for task list, scope of initial release
Date Wed, 11 Jun 2003 04:29:55 GMT
Brent Worden wrote:
> 
>>-----Original Message-----
>>From: J.Pietschmann [mailto:j3322ptm@yahoo.de]
>>Sent: Tuesday, June 10, 2003 3:04 PM
>>To: Jakarta Commons Developers List
>>Subject: Re: [math] proposed ordering for task list, scope of initial
>>release
>>
>>
>>Phil Steitz wrote:
>>
>>>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
> 
> 
> I would agree whole-heartedly.
> 

That's where I started, but then Tim and others convinced me that it was 
actually better/more convenient for users for us to behave more like 
java.Math and java's own arithmetic functions -- which use NaN all over 
the place.  Also, from a usage standpoint, if we use checked exceptions 
everywhere, this is a bit inconvenient for users.  We need to find the 
right balance.

I am one the fence on this whole issue.  I am interested in hearing more 
about what others may have in mind.

Phil

> Brent Worden
> http://www.brent.worden.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 




---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message