When is a good time to create a custom Exception class rather thanusing IllegalArgumentException mos

[-]

I always use IllegalArgumentException when the parameter suplied is invalid.

When is a good time to create a custom Exception class rather than using
IllegalArgumentException?

 

[Andrea Desole]

I always use IllegalArgumentException when the parameter suplied is
invalid.

When is a good time to create a custom Exception class rather than using
IllegalArgumentException?

in my opinion as soon as possible, so that you can check the exceptions
thrown and have a consistent exception handling mechanism in your code.

 

[Wibble]

in my opinion as soon as possible, so that you can check the exceptions
thrown and have a consistent exception handling mechanism in your code.

Unless your doing special handling with particular bad arguments, IAE is
good enough. IAE indicates a programming error, so the only correct way
to deal with it is to fix your code, not do something cute at runtime.

Its not useful to clutter your code with classes that add no value.

 

[Andrea Desole]

Unless your doing special handling with particular bad arguments, IAE is
good enough. IAE indicates a programming error, so the only correct way
to deal with it is to fix your code, not do something cute at runtime.

most of the exception classes indicate a programming error. Including,
usually, your own

Its not useful to clutter your code with classes that add no value.

maybe not (it depends on the cases), but the point with runtime
exceptions is that they are not checked. Here is something from the
tutorial:

http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html

At the end, if really new exception classes add no value, you can just
make one. It's not a big overhead.
I just find it good practice

 

[iamfractal]

I always use IllegalArgumentException when the parameter suplied is invalid.

When is a good time to create a custom Exception class rather than using
IllegalArgumentException?

An IllegalArgumentException, as you know, is a runtime exception,
i.e., you don't reasonably expect that your client can do anything to
recover from it.

So a good time to create a custom Exception class rather than using
IllegalArgumentException is to handle an argument from whose
illegality you do reasonably expect that your client can recover.

..ed

 

[Chris Smith]

At the end, if really new exception classes add no value, you can just
make one. It's not a big overhead. I just find it good practice

The problem is that custom exception classes don't just add no value;
they cause problems. Reasonably experienced Java programmers are
familiar with IllegalArgumentException, and they know what it means and
what it's used for. Your own exception may seem somewhat innocuous...
but if vendors of three dozen third-party libraries all do as you
suggest then the result can be a royal pain to deal with.

This is especially true if, as you seem to suggest, the new exception
classes are checked exceptions. There is no good reason to throw a
checked exception in response to a programming error. It's just not a
good decision, regardless of how difficult it is.

As always, the answer here depends on the context. It's ridiculous to
give unqualified advice to someone to declare their own exception class
without even knowing the nature of the condition they want to respond
to. It's equally ridiculous to never write new exception classes.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Andrea Desole]

The problem is that custom exception classes don't just add no value;
they cause problems. Reasonably experienced Java programmers are
familiar with IllegalArgumentException, and they know what it means and
what it's used for. Your own exception may seem somewhat innocuous...
but if vendors of three dozen third-party libraries all do as you
suggest then the result can be a royal pain to deal with.

three dozen third party libraries? Quite a lot

This is especially true if, as you seem to suggest, the new exception
classes are checked exceptions. There is no good reason to throw a
checked exception in response to a programming error. It's just not a
good decision, regardless of how difficult it is.

just because it's a programming error doesn't mean that you can't
recovery from it, or you can't handle it.

As always, the answer here depends on the context. It's ridiculous to
give unqualified advice to someone to declare their own exception class
without even knowing the nature of the condition they want to respond
to. It's equally ridiculous to never write new exception classes.

Okay, then your qualified advice is welcome.
Agreed on the dependency on the context

 

[Daniel Dyer]

just because it's a programming error doesn't mean that you can't
recovery from it, or you can't handle it.

Can you provide an example where it would make sense to handle/recover
from a programming error? If the program is broken fix it. Writing logic
to recover from a bug elsewhere in the program seems counter-productive.
If the argument is illegal, change the code so that it provides a valid
argument. Writing an exception handler that somehow forces the program to
continue will only lead to fragile software.

These "programming errors" are where the programmer failed to express
their intentions correctly in source code. Part of the program does not
work as it was intended to. If the intention of the program is not clear
it is unreasonable to expect the program to work correctly.

Can you imagine how frustrating it would be if exceptions like
IllegalArgumentException, ArrayIndexOutOfBoundsException and
ArithmeticExcepion were checked exceptions? Every array access would have
to be within a try...catch block, just in case you stuffed up with the
indexing. Every division would have to explicitly deal with the
possibility of division by zero (even if you can be certain that the
divisor is non-zero). And if your IllegalArgumentException was checked,
your method/constructor could be documented as follows:

1). Please provide valid arguments.
2). Please provide code to deal with your inability to follow the first
instruction.


Dan.

 

[Andrea Desole]

Can you provide an example where it would make sense to handle/recover
from a programming error? If the program is broken fix it. Writing
logic to recover from a bug elsewhere in the program seems
counter-productive. If the argument is illegal, change the code so
that it provides a valid argument. Writing an exception handler that
somehow forces the program to continue will only lead to fragile software.

You don't have to write an exception handler. You can also propagate the
exception.
Anyway, in any case when you have necessity to rollback (a database, a
file, maybe just writing data to a class), you need to catch whatever
exception, even if it's coming from a programming error.
I know, in that case I can simply catch a Throwable and do my error
handling, but my point was just that a programming error is not always
something you have to let go

These "programming errors" are where the programmer failed to express
their intentions correctly in source code. Part of the program does
not work as it was intended to. If the intention of the program is not
clear it is unreasonable to expect the program to work correctly.

as well as in many other cases when the error is not a programming error

Can you imagine how frustrating it would be if exceptions like
IllegalArgumentException, ArrayIndexOutOfBoundsException and
ArithmeticExcepion were checked exceptions? Every array access would
have to be within a try...catch block, just in case you stuffed up with
the indexing. Every division would have to explicitly deal with the
possibility of division by zero (even if you can be certain that the
divisor is non-zero). And if your IllegalArgumentException was
checked, your method/constructor could be documented as follows:

1). Please provide valid arguments.
2). Please provide code to deal with your inability to follow the
first instruction.

true. And this is the reason why RuntimeException is not checked.
At the end, as it usually is and as it has been pointed out already, it
depends on the context. Maybe I will look at it (I promise I will )
and I will decide to use RuntimeException more often, but I just like
the idea that my exceptions are checked. What can I say? I'm always
concerned I can forget something.

 

[Daniel Dyer]

You don't have to write an exception handler. You can also propagate the
exception.
Anyway, in any case when you have necessity to rollback (a database, a
file, maybe just writing data to a class), you need to catch whatever
exception, even if it's coming from a programming error.
I know, in that case I can simply catch a Throwable and do my error
handling, but my point was just that a programming error is not always
something you have to let go

Maybe we are using different definitions of "programming error". I/O can
go wrong even if the program is written perfectly. You can't, for
example, guarantee that some other process won't fill up the disk while
you are writing to a file or that there won't be a network problem. In
these cases I agree that a checked exception is best because it forces the
programmer to consider these situations. But for the narrower definition
of "programming error" that I was thinking of, where things are guaranteed
to work if you write the code properly, such as accessing an array or
calling a method with the right arguments, I think it's overkill.

Getting back to the original poster's question about the use of
IllegalArgumentException, I would say that it should be used to validate
that arguments are acceptable according to the specification of the method
(which should be documented). Therefore you should know for certain
before you call the method (or constructor) with a given set of arguments
whether an exception will result. If you know this for certain in advance
you can avoid it. If you can write the code in such a way that this
exception is guaranteed never to occur it makes no sense to make the
exception checked or even to catch it.

As Chris pointed out, there is no good reason to write another exception
type for this purpose. If you have arguments that are illegal, then use
java.lang.IllegalArgumentException. There's no need for a
com.mydomain.InvalidParameterUsageException or an
org.apache.commons.ThisMethodCallIsntQuiteRightException.

If however you are doing something more than just simple validation with
your arguments then IllegalArgumentException might not be right. Suppose
you are parsing a String that is passed in as an argument. The argument
might be considered illegal because it's in the wrong format, but maybe a
ParseException or something else is a better choice. Mostly it's a
judgement call depending on the specifics of the situation.

Dan.

 

[Chris Smith]

Getting back to the original poster's question about the use of
IllegalArgumentException, I would say that it should be used to validate
that arguments are acceptable according to the specification of the method
(which should be documented). Therefore you should know for certain
before you call the method (or constructor) with a given set of arguments
whether an exception will result. If you know this for certain in advance
you can avoid it. If you can write the code in such a way that this
exception is guaranteed never to occur it makes no sense to make the
exception checked or even to catch it.

Agreed. In some cases, the focus on avoidability is very enlightening.
I'd be more precise and say the question is who "should" realize that
the argument is wrong. In many cases, libraries are computationally
deterministic and it's possible to avoid passing bad arguments, but the
question is still decided by where the detection of bad arguments ought
to occur. If the calling code "should" have known about the problem
before calling the method, then it is a programmer error. If the code
being called is the first location that "should" recognize a problem
with the arguments.

For example, it may be a requirement that some argument needs to be
relatively prime to some intermediate result from a complex math
calculation. If the complex math calculation is pertinent to the
library's problem space, then the logic for checking the input most
likely logically belongs to the library. IllegalArgumentException is
not appropriate in that case. The same is true for most parsing code.

Invariably, when explaining this, someone asks about the standard API,
NumberFormatException, and Integer.parseInt. This is a border case, but
the reasoning is basically this: NumberFormatException should only be
used for data that's produced programmatically, stored as text, and then
read back. If nothing goes wrong, there is no possibility of getting a
badly formatted number. User input (which often uses parseInt in
practice, IME) ought to be using the java.text.NumberFormat class --
which, lo and behold, throws a checked exception onm failure. The
border-ness comes from the fact that some "advanced" users are
inevitably going to view and try to edit an application's internal data
files when they are stored as text. These users, when they screw
something up, might arguably deserve better than an application crash
for it.

As Chris pointed out, there is no good reason to write another exception
type for this purpose.

Hmm. I actually said there's no good reason to throw a checked
exception. Although you're obviously not thinking of this, there could
be a very good reason to throw a subclass of IllegalArgumentException,
which means writing a new exception type. Off-hand, this could be done
because it might be useful to include more information or context about
why the argument was illegal.

In any case, some time ago I wrote a short presentation for the Pikes
Peak Java Developers Group on exception handling practices. You can
find it at:

http://www.ppjdg.org/presentations/java_essentials/Exception Handling Practices.ppt

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Daniel Dyer]

Hmm. I actually said there's no good reason to throw a checked
exception.

OK, sorry. I read your first two paragraphs as if they were two separate
points.

Dan.