Discussion:
What exception to use with invalid data fields on object passed to business tier method?
(too old to reply)
davout
2007-05-07 14:06:36 UTC
Permalink
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.
Thomas Fritsch
2007-05-07 14:46:48 UTC
Permalink
Post by davout
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.
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;
}
...
}
Post by davout
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.
--
Thomas
Lew
2007-05-07 20:53:53 UTC
Permalink
Post by Thomas Fritsch
Post by davout
I have a question about what the convention is for throwing exceptions on
validating data passed to business tier objects.
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.
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.
--
Lew
Wojtek
2007-05-07 22:29:42 UTC
Permalink
Post by Thomas Fritsch
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.
--
Wojtek :-)
Reinder Verlinde
2007-05-18 22:25:53 UTC
Permalink
Post by Wojtek
Post by Thomas Fritsch
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
Lew
2007-06-04 15:05:39 UTC
Permalink
Post by Reinder Verlinde
Post by Wojtek
Post by Thomas Fritsch
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.
class myIllegalArgumentException extends IllegalArgumentException {
...
}
...
try {
...
} catch( myIllegalArgumentException e) {
...
} catch( IllegalArgumentException e) {
...
}
Better yet, use a checked exception. There also is no particular reason to
extend IllegalArgumentException - you could extend Exception or
RuntimeException directly.
--
Lew
Mich
2007-05-07 14:47:12 UTC
Permalink
Post by davout
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.
Why not create your own exception, such as NullAccountField with a different
message for each field?
Loading...