commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chuck Daniels" <c...@yahoo.com>
Subject RE: cvs commit: jakarta-commons/lang DEVELOPERS-GUIDE.html
Date Thu, 07 Aug 2003 06:25:16 GMT
> -----Original Message-----
> From: Phil Steitz [mailto:steitzp@yahoo.com]
> Sent: Thursday, August 07, 2003 4:11 PM
> To: Jakarta Commons Developers List
> Subject: Re: cvs commit: jakarta-commons/lang DEVELOPERS-GUIDE.html
>
>
> 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>

I agree with this kind of wording.  If there is a sensible way to handle
null or empty values, then do so and document it.

>
> 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>

I also agree with this.  It follows from the previous point that if there is
no sensible way to handle null or empty values, then throw an
IllegalArgumentException.  In particular, I like the practice of throwing an
IllegalArgumentException rather than a NullPointerException when there is no
way to handle a null value for a parameter.  I find that this practice can
help with debugging since adherence to it should generally mean that a
NullPointerException indicates a bug in the code that was called, whereas an
IllegalArgumentException indicates a bug in the caller's code.

>
> Phil
>
>
> --- bayard@apache.org 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: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
>
> ---------------------------------------------------------------------
> 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