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

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

 

[Thomas Fritsch]

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;
}
...
}

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.

 

[Mich]

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?

 

[Daniel Pitts]

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.

Generally, you separate GUI validation from business validation... The
form controller itself should check the input to prevent user error.
The business logic should do further validation to prevent programmer
error. In the form controller, its not an exception for a user to
make a mistake, as a matter of fact you should count on it ... It
is an exception if the user error is propagated to your business tier.
And for that purpose, IllegalArgumentException is appropriate.

 

[vysh]

Generally, you separate GUI validation from business validation... The
form controller itself should check the input to prevent user error.
The business logic should do further validation to prevent programmer
error. In the form controller, its not an exception for a user to
make a mistake, as a matter of fact you should count on it ... It
is an exception if the user error is propagated to your business tier.
And for that purpose, IllegalArgumentException is appropriate.

its always better if you do these routine validations in your form
controller itself.Incase if you are in need of any further
validations, you can always do it in your business tier.It will be
good if you follow a procedural approch towards the validations done
in your business tier for identifying the exact field which has
created the error.I mean,if you call your validation method in an
orderly way,you can always have an index of the validation failed.With
this specific one you can always identify the right field.

regards,
vaisakh.