common code and exceptions too many?

[frank]

Had a java design question to get what people think and what is
generally done. I've started to embrace more the use of throwing
exceptions (I'm an old C programmer did not have such a thing always
return codes) particular in the design of common code. I have been
having the tendency to let these common packages/methods/libs throw all
the base level exception and let the implementor/user of the class
decide what to do on an exception. The philosophy being that the common
code probably can not make the best decision in every case.

Well in some of these I can have a number of individual exceptions (10
maybe) particularly then you start having any type of class hierarchy.
Now some people are complaining that too many.

My argument back is you can just check the ones you want to then use a
generic catch all what's the big deal? Am I missing something?


Thanks,

Frank

 

[HalcyonWild]

Had a java design question to get what people think and what is
generally done. I've started to embrace more the use of throwing
exceptions (I'm an old C programmer did not have such a thing always
return codes) particular in the design of common code. I have been
having the tendency to let these common packages/methods/libs throw all
the base level exception and let the implementor/user of the class
decide what to do on an exception. The philosophy being that the common
code probably can not make the best decision in every case.

Well in some of these I can have a number of individual exceptions (10
maybe) particularly then you start having any type of class hierarchy.
Now some people are complaining that too many.

My argument back is you can just check the ones you want to then use a
generic catch all what's the big deal? Am I missing something?

You need to read some more on exception handling.

Well, the only advantage I can think of exception handling ( and
specific exception handling ), is the separation of errorhandling from
your logic.

Throwing specific exceptions indicates the user of your code, about the
error.

Like, if you are trying to add premium on an insurance policy, given
the policy number and premium amount. If insurance policy is not found,
you can throw an exception to the caller, telling that the policy
number is not found.

Of course, you need to figure out an optimum level, you cannot just go
around creating a new exception class for each and every error. You
might club some exceptions common to a module together.

Read this too, though it might be a bit intimidating if you are new to
Java.

http://www.mindview.net/Etc/Discussions/CheckedExceptions

 

[pkriens]

Exceptions in Java are a good idea gone bad by overdoing it.Checked
exceptions are a nightmare. They are so hard to use that people swallow
exceptions (which is as bad as it gets) or they invent a new exception
for every layer that collects exceptions of the lower layer. Quite
often the real cause of the problems is 4-5 layers down. Java added the
getCause in 1.4 to allow for navigation through this space.For exampe,
if I call a database, do I want to get MySqlException, that points to a
some intermediate exceptions, that contain the final cause which
happens to be an IOException on a certain file. Only the last exception
is relevant.

Additionally, exceptions should be about exceptional cases.
Unfortunately, exceptions have been used to provide extra information
from the callee tot he caller. For example FileNotFoundException is not
an exceptional case, it is a normal event. Using exceptions for this is
expensive in runtime as well as annoying to read.

So exceptions are great, you should just not be forced to wrap your
exceptions in silly intermediates or be forced to specify all possible
exceptions that could be thrown. Most code should not try to handle the
exception, only top level code needs the exceptions to recover.

 

[Timbo]

Additionally, exceptions should be about exceptional cases.
Unfortunately, exceptions have been used to provide extra information
from the callee tot he caller. For example FileNotFoundException is not
an exceptional case, it is a normal event.

That depends on how you use them. For every exception, there
should be a way to check whether that exception is going to be
thrown (although perhaps this is not always possible). In the
example of FileNotFoundException, you can use the methods in the
File class to check whether the file is readable, writable, etc.
Therefore, if you use these and the exception is being thrown, you
know that something irregular is going on, so an exception is
suitable.

 

[pkriens]

There is always a window between checking and doing ... meaning that
you can get the exception even though you checked.

 

[Roedy Green]

There is always a window between checking and doing ... meaning that
you can get the exception even though you checked.

If that is happening, you need a synchronised block.

 

[Thomas Hawtin]

If that is happening, you need a synchronised block.

That doesn't help in the cropped example of whether a file exists or not.

Tom Hawtin

 

[Benji]

If that is happening, you need a synchronised block.

Granted, he didn't include any context in his original post, but that's not
really related. You can't use a synchronized block to fix a
FileNotFoundException. Since we're talking about exceptions...normally
checked exceptions are trigged from circumstances based on input from
outside of the JVM.

 

[Roedy Green]

That doesn't help in the cropped example of whether a file exists or not.

If you have other programs fooling with your files as you use them,
that is the least of your worries.

 

[Timbo]

There is always a window between checking and doing ... meaning that
you can get the exception even though you checked.

I don't think that a file being moved between checking its
existence and opening it is a normal event in many systems.

 

[pkriens]

Hmm. I am not sure in what world you live but in my distributed world
this is a very concrete possibility. It is definitely not something you
want to ignore.

 

[Thomas Hawtin]

If you have other programs fooling with your files as you use them,
that is the least of your worries.

I'd have problems with any modern desktop operating system that didn't
allow it to happen.

Tom Hawtin