> -----Original Message----- > From: Phil Steitz [mailto:[EMAIL PROTECTED] > >> > >>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.
Here's a saying I've used in the past when debating colleagues: "Just because someone else does something, that doesn't make it right." :) 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. The big problem I have with returning NaN is the caller has little knowledge why NaN is being returned. If an exception is thrown, preferably a specialized exception like ConvergenceException, the caller knows precisely the reason for failure and can take appropriate recovery action. > > Phil Brent Worden http://www.brent.worden.org --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
