On Tue, 26 Aug 2003, David Graham wrote:
> --- __matthewHawthorne <[EMAIL PROTECTED]> wrote:
> > I've been thinking about RuntimeExceptions and assertions...
> >
> >
> > --------------------------------
> > Intro
> > --------------------------------
> > A RuntimeException is typically thought of as a way to indicate misuse
> > of a
> > particular method. As I've always seen it, it is not meant to be
> > caught.
> >
> > The majority of methods that I write include an initial block which
> > validates
> > the arguments, such as:
> >
> > public void doSomethingWith(Object o) {
> > if(o == null) {
> > throw new IllegalArgumentException("Object cannot be
> > null.");
> > }
> > }
> >
> > I think this is OK, but there are some people who believe that even this
> > is
> > overkill. If I were to abandon the null check, a NullPointerException
> > would be
> > thrown which would indicate the same thing - programmer error.
>
> NPE exists so that you don't have to code those boring null checks in all
> your code. It is indeed overkill to throw IllegalArgumentException for
> null parameters. Further, the standard Java classes use NPE to indicate
> programmer error.
I don't agree with this -- there are often conditions where passing in
null for one method will not throw an NPE until it is accessed in a
different method. This can be difficult to track down, especially in a
third party library.
I think IAE, or better yet o.a.c.l.NullArgumentException is useful in
many cases.
michael
>
> >
> > The flaw that I see in this is the lack of details about the error. A
> > NullPointerException with a line number is useless to somebody who does
> > not have
> > access to the source code.
>
> The stack trace provides enough details to debug the source of the error.
> It is not useless to someone without the source because their offending
> method call will be somewhere in the trace, instantly locating the
> problem.
>
> > There is also a certain degree of confusion
> > as to
> > where the error lies. If my code calls apache code which calls sun
> > code, who is
> > responsible?
>
> You are. If you pass null to a method that doesn't explicitly state that
> null is allowed it's your error.
>
> >
> >
> > --------------------------------
> > Idea
> > --------------------------------
> > I like Java 1.4's assertion system, especially the ability the turn the
> > assertions on or off for certain packages. I would like to be able to
> > provide
> > similar functionality that allows for more flexibility in the error
> > handling,
> > which could be especially useful in pre-1.4 code.
> >
> > Here's a rough idea:
> >
> >
> > class AsserterFactory
> > Asserter getAsserter(String name)
> >
> > interface Asserter
> > void assertTrue(boolean condition, String message)
> >
> > class Java14Asserter
> > void assertTrue(boolean condition, String message)
> > assert condition : message;
> >
> > class StandardAsserter
> > void assertTrue(boolean condition, String message)
> > if(!condition) {
> > throw new IllegalArgumentException(message)
> > }
> >
> > class PassiveAsserter
> > void assertTrue(boolean condition, String message) {
> > // Does nothing
> > }
> >
> >
> > The asserter name could be a package name, a class name, or some other
> > type of
> > identifier. The configuration of these details may require system
> > properties
> > or a default asserter.properties file to set up different asserters.
> >
> > I can think of 2 difficulties presented by this approach, more
> > specifically,
> > with the dynamic nature of the RuntimeExceptions that a method may
> > throw.
> >
> > 1) Unit tests catch RuntimeExceptions to validate method behavior,
> > if assertions
> > were pluggable, switching them would cause a lot of tests to fail.
> >
> > 2) The RuntimeExceptions that a method throws could not be
> > documented.
> >
> >
> > --------------------------------
> > Conclusion
> > --------------------------------
> > Any thoughts or ideas? Repetitive coding of validation and
> > exception handling is starting to make me think that there is a better
> > way.
>
> The better (and standard) way is to utilize NPE.
>
> > There are even similar examples in [lang], where null-handling had to be
> > updated for tens of methods at a time.
>
> This is a known drawback in libraries that choose to check for null
> instead of allowing the runtime to throw NPE.
>
> >
> >
> > Imagine a similar concept, such as
> >
> > Validator
> > validate(Object o)
> >
> > StringValidator
> > validate(Object o) {
> > String s = (String)o
> > // Validate s
> > }
> >
> >
> > Where users could supply their own validator:
> >
> > StringUtils.setValidator(StringValidator v)
> >
> > and be guaranteed that the validate method would be called on any String
> >
> > that is
> > passed in.
> >
> > Thanks in advance for any replies, my apologies for the chaos.
>
> The proposed solution is much worse than the perceived problem. Java
> programmers instantly know how to debug a NPE in a stack trace. Adding
> some convoluted validation/assertion scheme puts an undue burden on the
> library code and is likely to confuse the developer.
>
> David
>
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
