«

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?

- wrote:
> 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.

Andrea Desole wrote:
>
>
> - wrote:
>
>> 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.
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.

Wibble wrote:
> 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/tutor...s/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

- <> wrote in message news:<42d34b8c$>...
> 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

--
www.EdmundKirwan.com - Home of The Fractal Class Composition.

Andrea Desole <> wrote:
> 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

Chris Smith wrote:
>
> 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

On Tue, 12 Jul 2005 15:56:22 +0100, Andrea Desole
<> wrote:
> Chris Smith wrote:
>> 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.

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.


--
Daniel Dyer
http://www.dandyer.co.uk

Daniel Dyer wrote:
>
> 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.

On Tue, 12 Jul 2005 18:40:36 +0100, Andrea Desole
<> wrote:
> Daniel Dyer wrote:
>> 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

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.ThisMethodCallIsntQuiteRightExc eption.

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.



--
Daniel Dyer
http://www.dandyer.co.uk