Why not »throws AnimalException« here?

 It is not wrong to have them if they serve a
 purpose. But this does not mean that they need
 to be used in that throws-clause.

On an unrelated topic, this is NOT rethrowing the exception.  This is throwing
a new exception with the same message string.  It's generally a bad thing.
You should either
  throw e; // rethrow the exception
or
  throw new DogException(e); // throw a new message that is chained.

This preserves the stack trace and information in the original exception,
whereas just using e.getMessage() throws it all away.

...

Maybe - it's complex enough that there's no perfect right and wrong.
Certainly don't create exception types unless they mean something.  And
certainly create them if needed.  I think your problem is that you're trying
to hide the superclass's AnimalException.  Don't - a dog _IS_ an animal, and
it's it's very reasonable for dog.doIt() to throw AnimalException for
exceptions that are common to all animals, and DogException for exceptions
specific to dogs.
--
Mark Rafn    dagon@dagon.net    <http://www.dagon.net/>

Sure. Don't do it.  Let Dog throw the Animal exception.  It generally makes
no sense to relabel it as a DogException.

I'm answering this a month late, so the original poster might not even seen
the answer, and since he didn't use a real email address, I can't CC to
him.

However, the answer is that there is no reason to subclass exceptions to
mirror the classes throwing them.  The expectations should instead, mirror
the types of problems that cause them.  If the exception is AnimalHitByCar,
then both Dogs and Cats can throw the same exception.  It makes no sense to
subclass AnimalHitByCar to create both CatHitByCar and DogHitByCar just
because they are thrown by different classes.  If there's only one error
which happens in Animal.doIt(), then there should only be one exception
defined.

Exceptions are defined to report unique error conditions, not unique
sources of the errors.  You need a different exception for each type of
error that can cause it to be thrown - unless you think the errors will all
be handled the same way by the catching code - in which case you only need
one exception for all of them: AnimalException.

There are reasons to catch and rethrow Exceptions. You do it so you can
change the implementation of a class without changing it's API.  You want
it to throw only one type of error on an exception - like Dog.fetch()
throws DogFailsToFetchException.  As you change the code in fetch(), the
other classes you use might throw different exceptions which prevents fetch
from finishing correctly, like "leg() throws BrokenBoneException". But
instead of allowing all the different low level causes of why fetch failed
to propagate update, you just rethrow it (correctly) as a
DogFailesToFecthException with a cause of BrokeBoneException.  That way,
the code which uses Dog.fetch() doesn't have to change every time you
change the Dog.fetch() method.