Amount of exceptions needed to make java code robust, but not cluttered

Question

Lately I've been paranoid about some of my java classes and I've been inserting exceptions everywhere where I can to make sure I'm not setting values to null or getting values if they aren't initialized properly. At first, this seemed like a good idea following the standard pattern of validation:

public method doSomething(arg1)
{
    if(!isValidArg1(arg1))
    {
        throw new IllegalArgumentException;
    }

    ...
}

But this is getting to the point where each and every one of my getters/setters looks like this:

public String getLogicalName()
{
    if (logicalName == null)
    {
        throw new UninitializedAttributeException("attribute: logical name.");
    }

    return logicalName;
}

public void setLogicalName(String logicalName)
{
    if (StringUtils.isBlank(logicalName))
    {
        throw new IllegalArgumentException("attribute: logical name, illegal value: null, empty or whitespace.");
    }

    this.logicalName = logicalName;
}

Apart from losing too much time on coding these trivial methods, I feel like i'm overdesigning. Sure, debugging becomes more straigthforward, but its not like a normal nullpointerexpection doesn't show you what the problem is.

The main reason why I throw all these exceptions is because I want to present the end user on the front end with a clear message of what went wrong. I'm disappointed by some programs who just catch(Exception e) wrapped around all their code, and if something goes wrong somewhere all the user sees is "something went wrong somewhere but I can't tell you what and where.". However, most of the time, the user cannot do anything about these exceptions because it's a development issue (although it is nice the user can tell the developer exactly what went wrong...). So is this overdesigned?

I'm in doubt about this. How do you other developers cope with this? What are some cases where explicitly checking the input/output values of a method is good practice, and what are cases where its redundant and clutters up the source code? Can a line be drawn?

Answer 1

Input validation is always a good idea - the earlier this is done, the better. I recommend doing that for all non-private methods. Some people advocate doing this even for private methods too, just in case visibility is changed at any point. Others trust their own package and only validate public and protected methods.

There should be no need to perform validation in a getter. You have full control over the contents of your class, so your fields should not enter a bad state. The input validation ensures you are never setting state values that you don't later approve of in a getter. Remember defensive copying when you return mutable objects from a getter.

Regarding error messages for users - just concentrate on throwing exceptions that are meaningful for your method. How this is later presented to the user is up to the presentation layer. All you can do is accurately describe what went wrong in the context of your class.

Related reading:

• "Item 61 - Throw exceptions appropriate to the abstraction", (Effective Java, Second Edition).

• Avoiding != null statements

Answer 2

If you are interested in the design side of these checks, Microsoft have an interesting system for C# that allows you to define the input requirements of a method and what you can expect back as output. It takes things further than runtime checks because it's expected to combine with static analysis tools.

Code Contracts

http://msdn.microsoft.com/en-us/library/dd264808(v=vs.110).aspx

I tried looking for something similar in Java. This might be of interest if you want something to use right away:

guava-libraries: PreconditionsExplained

https://code.google.com/p/guava-libraries/wiki/PreconditionsExplained