commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From __matthewHawthorne <mhawtho...@alumni.pitt.edu>
Subject [all] RuntimeExceptions, assertions, and pluggable validation
Date Tue, 26 Aug 2003 19:01:28 GMT
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.

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


--------------------------------
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.
There are even similar examples in [lang], where null-handling had to be
updated for tens of methods at a time.


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.



Mime
View raw message