It's hard to express exactly what we want to say here. I still don't think that we've got it quite right. I think the original wording was actually closer to describing current practice, though "supressing exceptions" is too strong. The idea is that we want to define contracts so that methods do sensible things for all sorts inputs, including nulls, badly formatted numeric strings, etc., avoiding RTEs when there is a reasonable alternative. At least that's how I would characterize the 'nice' and 'quiet' spirit (language that I like personally).
So... I would recommend something more like: <li>Methods should generally be 'nice' and 'quiet'. Contracts should be defined to handle as broad a set of input values as possible, handling null, empty or malformed parameters without throwing exceptions whenever there is a sensible way to do this. In any case, behavior for all null and boundary values should be clearly documented in the javadoc method comments.</li> Another (maybe controversial) current practice thing that is not mentioned is something like: <li>Methods should not in general throw NullPointerExceptions. Null inputs should either be handled without exception or an IllegalArgumentException should be thrown instead</li> Phil --- [EMAIL PROTECTED] wrote: > bayard 2003/08/06 20:14:27 > > Modified: lang DEVELOPERS-GUIDE.html > Log: > Reworded the comment on quiet methods returning Null patterns. > > Revision Changes Path > 1.4 +2 -3 jakarta-commons/lang/DEVELOPERS-GUIDE.html > > Index: DEVELOPERS-GUIDE.html > =================================================================== > RCS file: /home/cvs/jakarta-commons/lang/DEVELOPERS-GUIDE.html,v > retrieving revision 1.3 > retrieving revision 1.4 > diff -u -r1.3 -r1.4 > --- DEVELOPERS-GUID<.html 30 Jul 2003 23:58:36 -0000 1.3 > +++ DEVELOPERS-GUIDE.html 7 Aug 2003 03:14:26 -0000 1.4 > @@ -59,8 +59,7 @@ > <li>deal with one class or interface and its variations > (subclasses)</li> > <li>provide methods that perform useful utility functions</li> > <li>the class will not be final</li> > -<li>methods should generally be 'nice' and 'quiet'. That is, they > should > -suppress Exceptions when sensible. </li> > +<li>for null parameters, rather than throwing an Exception, consider > performing a Null patterned concept, such as returning 0 or ""</li> > </ul> > > <p>A utility class can act as a factory for specific implementations > of a class or > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
