Want to understand Exceptions

Question

some basic questions regarding exceptions handling:
* I have some types of exceptions which are not code related but i want to handle them seperately. They include class instantion failure, could not get database connection etc. Their handling in all cases will be same (log it and send to Administrator). I was thinking about creating a seperate exception "InfrastructureFailureException" which will be thrown whenever such errors happens. But I am not sure this is a good idea. The reason is that in a logical-unit-of-work this type of exception can be thrown more than once. That means I have to use more than one try block. For example to get a Connection is a 2 step process:
try {
// get Connection Manager
} catch (InfrastructureFailureException ife) {
try {
// get Connection from Connection Manager
} catch (InfrastructureFailureException ife) {
Is there any better approach?
* i have defined a retrieve exception for each domain object, which is thrown by each retrieval operation. So I have a EmployeeNotFoundException which is thrown by getEmployeeById(int employeeId) DAO method. Similarly I have a DepartmenNotFoundException which is thrown by getDepartmentById(int deptId) DAO method.
Now I am thinking the above exceptions can be grouped as they belong to retrieve. So create a RetrieveFailedException and use it as a parent of the above exceptions. Is it a good idea?
I am also thinking about applying the same logic for INSERT and UPDATE (InsertFailedException and UpdateFailedException will be used as parents)
* Suppose an exception is thrown. I am having problems deciding which method to let handle this exception in the call stack.
Thanks

Answer 1

>>
However, for those who do develop applications,you
will either use a library (in which case it willbe
exceptionally relevant, pardon the pun). Or youwill
develop your own exceptions. Often I develop one for large applications.
Sometimes I develop one or two for a single layer.
Never more.
A library that does that is probably doing something
wrong.
An application that developes many is probably doing
something wrong as well. In my experience, that
happens because the developers are applying the
standards of library developement to application
developement.
Libraries are developed to serve the needs of
different users and with the intent that they will be
definitely be used in ways that the library
developers did not anticipate. Application are
developed to meet very specific guidelines. The
goals of both are different. Thus the goals and
functionality of each are different.
I agree. However, I make a distinction (see below) in types of exceptions. What the OP referred to are what I implement as 'unchecked' exceptions. These also seem to comport with your conception of an exception: that they
are truly exceptional. Truly exceptional circumstances are generally not recoverable. The unchecked data access framework of Spring is an excellent example of this. As these resembled the OP's original needs, I pointed out that library. In an actual application, I would use the library, customizing these exceptions to my own needs, or simply catching them in a front controller to display an error message to the user.
In either case, seeing
how an established library was constructed should
give you ideas on how your own exceptions might be
classified. I doubt it. Unless you are a library developer.
See above.
Data access exceptions are data access
exceptions. You may not need something asfull-blown
as Spring's data access exceptions, butundoubtedly
you will use at least a few.Yes - a few.
That having been said, in real applications, the
majority of important exceptions will be your
checked, business/model exceptions. Concentrateyour
efforts there. Worrying about whether I shoulduse
java.io.IOException or
com.foo.exception.NetworkException will distractyou
from the exceptions you actually need to write.In real applications, at least the ones that I have
worked on, exceptions are exactly that exceptions.
They are not anticipated, they are not expected and
d in normal operations they should never occur. They
do not need to be classified because any such
classification would suggest that they are
correctable when in reality, because they are
exceptions, they are not.
The customer help desk doesn't care whether the
database is down, or if there is a duplicate
insertion error, nor that the type specifier
definition is missing in a table. All of them means
that the customer service person can not do their job
and all mean that they have to call someone else who
will have to fix it. And to the person that fixes it
seperate exceptions will have gain no benifit if
there are multiple exceptions or one.
Exactly. This is why they are unchecked and intercepted only at a front controller level to display a generic error page to the user, and potentially issue a page for support or entry into a log file.
Additionally application developers often,
incorrectly, use exception hierarchies in such a way
that it completely destroys the information needed to
actually fix the problem in the first place, because
they end up throwing away the original exception
because they found a "better" one to return.However, I disagree with your notion of 'exceptional' exceptions. This is not in any way to say my way is 'correct', but rather to simply explain it.
Any time I read a business requirement that has an abnormal path of exceution (balance below zero, user account not found, accessing the flux capacitor on an even-numbered day of the month, etc.), I create a checked, business exception for that use case. It has an English-readable name, and any business user would be able to understand what that exception is for.
When developing the application, these exceptions ensure that all expected business exceptions are accounted for. It also reminds me of what abnormal paths of execution the business users have specified. Any business service should handle the possible business exceptions involved in a given call.
The remainder of exceptions are 'exceptional' exceptions. These I leave as unchecked. Sometimes I use a library or framework ala Spring, especially for data access or XML parsing or other general failure possibilities. Other times, when none are available, I create my own. However, they are always unchecked.
- Saish