Another exception handling question

[mike]

public void myMethod (String name){

if(!condition1){
throw new IllegalArgumentException("A message ");

}

if(!condition2){
throw new IllegalArgumentException("Another mesage");

}


}

When I call myMethod I want to distinguish between the different
reasons for the same exception. Is it better to make my own
exception ? What is my good practice?

cheers,

//mike

 

[skyeweaver]

public void myMethod (String name){

if(!condition1){
throw new IllegalArgumentException("A message ");

}

if(!condition2){
throw new IllegalArgumentException("Another mesage");

}
}

When I call myMethod I want to distinguish between the different
reasons for the same exception. Is it better to make my own
exception ? What is my good practice?

cheers,

//mike

Hi Mike,
I think one of solutions is to extend either Exception or
IllegalArgumentExceptionClass and have it contain a new member
variable of numeric type, say integer. Next, provide your new class
with a constructor that takes at least a value for this new variable.
You can then think of assigning an integer to each cause that you plan
to handle and throw exception instantiated using that particular
value. Outside your method, handle your exception and design a switch
construct in which you will catch appropriate erroneous situation
based on that numeric value. For ease of use it's good to have a
mapping of integers to String constants and use meaningful names so
that they are easily recognized.

 

[Arne Vajhøj]

Already too complicated for an Exception class, usually.


Use of a 'switch' to distinguish type is an antipattern in O-O programming.

I could not agree more.

At best you could use an enum for this idiom, but it shouldn't be
necessary.

If you are not deciphering the exception but just reporting it, then use
of a standard Exception class with different messages is just fine.
Eric is right that you should never attempt to parse Exception messages
to determine action. If you must catch and decipher the Exception,
follow his advice and use a custom exception hierarchy.

Design it well! A chaotic and disorganized exception hierarchy, as one
might imagine, would not help your architecture.

Yep.

And since it is easier to handle two exceptions identical than
the same exception different, then having an exception class per
exception type is the most future proof.

Arne

PS: Why do I think of SQLException ?

 

[Arved Sandstrom]

[ SNIP ]

Also, remember the difference between checked exceptions and runtime
exceptions. The former are for conditions outside programmer control
(e.g., unavailable resource), and are reported as part of a method's
signature. The latter are for conditions the programmer should have
prevented, such as an illegal argument value. Runtime exceptions are not
part of the method signature; they just take the client code by surprise.

Although in the case of a number of exceptions derived from
RuntimeException, it does make sense to catch them in the calling code.
Because they are not in fact programming errors. For example, consider the
method Integer.parseInt(String). It exists because it's meant to be used,
and it throws a NumberFormatException (which is an unchecked exception). The
only way to avoid throwing an NFE using that method is to validate the
String before you call parseInt, but hell, parseInt is doing precisely that.
So most people I know - myself included - use parseInt (or equivalent
methods) to do the validation, and catch the NFE right then and there.

NumberFormatException is a decent example of an exception which could go
either way. There are really three classes of exceptions:

(a) exceptions that signal recoverable conditions, and you want the calling
code to do something meaningful with it right away. For example,
FileNotFoundException. This is not a programming error if you can't find a
file, you can recover from it, and generally you do want to address the
issue right away. It's a good example of a checked exception;

(b) exceptions that signal situations that cannot be reasonably dealt with.
For example, NullPointerException. This just shouldn't happen. If a method
can return a null, for example, you should have code to deal with it. If you
don't, it's a programming error. It's a good example of an unchecked
(runtime) exception that you don't usually want to catch anywhere;

(c) exceptions that could be recovered from, but you don't necessarily want
to. Consider NumberFormatException again. In some circumstances it's thrown
by a parsing method that has a reasonable expectation of getting a string
which is not a valid number, so it's not a programming error - you catch it
and deal with it. But consider perhaps the case of using it to convert
string values in a flat file, all of which are supposed to be integers (they
were produced by another program)...if one of those strings is not
convertible to an int, maybe you want some discretion as to where in the
calling chain you explicitly handle that NFE, or possibly you don't want to
handle it at all - you want the program run to barf.

For exceptions I myself fall into the middle camp. To a large degree I go
with what Josh Bloch suggests for exceptions, but I also believe that there
are quite a few unchecked exceptions that can in some circumstances be
caught and dealt with (and not treated as programming errors).

AHS

 

[Arne Vajhøj]

Although in the case of a number of exceptions derived from
RuntimeException, it does make sense to catch them in the calling code.
Because they are not in fact programming errors. For example, consider the
method Integer.parseInt(String). It exists because it's meant to be used,
and it throws a NumberFormatException (which is an unchecked exception). The
only way to avoid throwing an NFE using that method is to validate the
String before you call parseInt, but hell, parseInt is doing precisely that.
So most people I know - myself included - use parseInt (or equivalent
methods) to do the validation, and catch the NFE right then and there.

NumberFormatException is a decent example of an exception which could go
either way. There are really three classes of exceptions:

(a) exceptions that signal recoverable conditions, and you want the calling
code to do something meaningful with it right away. For example,
FileNotFoundException. This is not a programming error if you can't find a
file, you can recover from it, and generally you do want to address the
issue right away. It's a good example of a checked exception;

(b) exceptions that signal situations that cannot be reasonably dealt with.
For example, NullPointerException. This just shouldn't happen. If a method
can return a null, for example, you should have code to deal with it. If you
don't, it's a programming error. It's a good example of an unchecked
(runtime) exception that you don't usually want to catch anywhere;

(c) exceptions that could be recovered from, but you don't necessarily want
to. Consider NumberFormatException again. In some circumstances it's thrown
by a parsing method that has a reasonable expectation of getting a string
which is not a valid number, so it's not a programming error - you catch it
and deal with it. But consider perhaps the case of using it to convert
string values in a flat file, all of which are supposed to be integers (they
were produced by another program)...if one of those strings is not
convertible to an int, maybe you want some discretion as to where in the
calling chain you explicitly handle that NFE, or possibly you don't want to
handle it at all - you want the program run to barf.

For exceptions I myself fall into the middle camp. To a large degree I go
with what Josh Bloch suggests for exceptions, but I also believe that there
are quite a few unchecked exceptions that can in some circumstances be
caught and dealt with (and not treated as programming errors).

I agree with that.

Catching NFE makes perfectly sense if it is an exception that is
exceptional like reading from a file that is supposed to contain
valid data. For parsing input from user validation should probably
be done.

And I do not agree with the "we can't do anything so let us just exit"
philosophy. There are lot of apps in the server side or batch style
processing where it makes perfectly sense to try continue running.

The "we can't do anything so let us just exit" philosophy is in
my opinion a desktop app philosophy.

Some types of exceptions/errors are just impossible to handle and some
are too unsafe to handle. But those that are neither should be recovered
from.

Arne



Arne