What exception to use with invalid data fields on object passed to business tier method?

Thread view:

davout - 07 May 2007 15:06 GMT

I have a question about what the convention is for throwing exceptions on
validating data passed to business tier objects.

If I have a business tier service like where 'AccountManager', a business
tier that maintains accounts...

public class Account {
...
private String fTitle;
private String fAccountCode
....
}

public class AccountManager {
...
public void addAccount(Account aNewAccount);
...
}

... and any new account must have a non null title and a non-null account
code.

If the 'aNewAccount' parameter is passed with a null title field or a null
account code field what type of exception should I throw? Should the
business tier code be throwing an IllegalArgumentException? If so, how can
my GUI tier determine what field failed the validation test? Or should I use
a separate custom exceptions for each validation point? One custom exception
for title, another for alias etc.

Reply to this Message

Thomas Fritsch - 07 May 2007 15:46 GMT

> I have a question about what the convention is for throwing exceptions on
> validating data passed to business tier objects.
[quoted text clipped - 17 lines]
> ... and any new account must have a non null title and a non-null account
> code.

Given your requirement above, I think the natural place for these checks
would be the the Account constructor (and its setTitle/setAccountCode
methods, if there are such) rather than the AccountManager:
public class Account {
...
public Account(String title, String accountCode) {
if (title == null)
throw new IllegalArgumentException("title is null");
if (accountCode == null)
throw new IllegalArgumentException("accountCode is null");
fTitle = title;
fAccount = accountCode;
}
...
}

> If the 'aNewAccount' parameter is passed with a null title field or a null
> account code field what type of exception should I throw? Should the
> business tier code be throwing an IllegalArgumentException? If so, how
> can my GUI tier determine what field failed the validation test? Or should
> I use a separate custom exceptions for each validation point? One custom
> exception for title, another for alias etc.

I personally would prefer IllegalArgumentException for all (with different
detail messages), instead of lots of custom exception classes.

Signature

Thomas

Reply to this Message

Lew - 07 May 2007 21:53 GMT

davout wrote:

>> I have a question about what the convention is for throwing exceptions on
>> validating data passed to business tier objects.
[quoted text clipped - 4 lines]
>> I use a separate custom exceptions for each validation point? One custom
>> exception for title, another for alias etc.

> I personally would prefer IllegalArgumentException for all (with different
> detail messages), instead of lots of custom exception classes.

I concur with Thomas, although there really is no well-established convention.
The best practice is to use the exception that makes the most sense, which
Thomas's sure seems to do. You ask for an exception that indicates that an
argument is illegal, and Hey, presto! java.lang.IllegalArgumentException
provides exactly that, as an unchecked Exception.

There is an argument to use NullPointerException if the null-pointerness is
what's most important to you, as opposed to IllegalArgumentException if the
illegal-argumentness is what's most significant.

In the world of RuntimeExceptions there's almost always a suitable one
available in the standard API, usually from java.lang.

For checked Exceptions there's a better case for writing (usually only) one
custom, application-specific Exception that uses any underlying Throwable as
its cause. Creating a hierarchy of custom (checked) Exceptions is possible
but to my mind offers little to negative benefit.

The question of whether to throw checked or unchecked Exceptions is subtler.
Think as an API designer when pondering it.

Signature

Lew

Reply to this Message

Wojtek - 07 May 2007 23:29 GMT

Thomas Fritsch wrote :

> I personally would prefer IllegalArgumentException for all (with different
> detail messages), instead of lots of custom exception classes.

Except where you want to control which exception gets handled where.

The alternative is to parse the exception message (or custom flag) and
if you do not want to handle it there, re-throw the exception. Not as
clean as a custom exception class.

Signature

Wojtek :-)

Reply to this Message

Reinder Verlinde - 18 May 2007 23:25 GMT

> Thomas Fritsch wrote :
> > I personally would prefer IllegalArgumentException for all (with different
> > detail messages), instead of lots of custom exception classes.
>
> Except where you want to control which exception gets handled where.

In that case, you can do:

class myIllegalArgumentException extends IllegalArgumentException {
...
}

...

try {
...
} catch( myIllegalArgumentException e) {
...
} catch( IllegalArgumentException e) {
...
}

Reinder

Reply to this Message

Lew - 04 Jun 2007 16:05 GMT

>> Thomas Fritsch wrote :
>>> I personally would prefer IllegalArgumentException for all (with different
[quoted text clipped - 16 lines]
> ...
> }

Better yet, use a checked exception. There also is no particular reason to
extend IllegalArgumentException - you could extend Exception or
RuntimeException directly.

Signature

Lew

Reply to this Message

Mich - 07 May 2007 15:47 GMT

>I have a question about what the convention is for throwing exceptions on
>validating data passed to business tier objects.
[quoted text clipped - 24 lines]
> I use a separate custom exceptions for each validation point? One custom
> exception for title, another for alias etc.

Why not create your own exception, such as NullAccountField with a different
message for each field?

Reply to this Message

What exception to use with invalid data fields on object passed to business tier method?

Free Magazines