Building an Exception Layer

[Rizwan]

I am trying to build an Exception Layer for a new system. The exceptions I
want to catch are :
* system/configuration failures e.g., Hibernate configuration file missing
etc. (StructureException)
* system access voilation e.g. wrong user id etc. (PermissionException)
* business rules voilation (BusinessRulesException)
* data access voilation (DAOException)

My question is should these above Exception sub-classes be inherited from
Exception or RuntimeException? Please explain why?

In this system I am planning to use Hibernate and Struts. StructureException
will be used in Hibernate and Struts initialization. I was thinking about
creating 2 classes HibernateStructureException and StrutsStructureException
inherited from StructureException and using them in respective code. What do
you guys think?

Thanks

Thanks

 

[Rizwan]

what i can think of is that PermissionException and BusinessRulesException
inherites from Exception while StructureException and DAOException inherites
from RuntimeException.

 

[iamfractal]

what i can think of is that PermissionException and BusinessRulesException
inherites from Exception while StructureException and DAOException inherites
from RuntimeException.

Don't inherit from RuntimeException. See
http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html

..ed

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

 

[Rizwan]

ok so all four exceptions has to be inherited from BaseException. thanks

 

[Chris Smith]

ok so all four exceptions has to be inherited from BaseException. thanks

One more comment: assuming that these exceptions will generally be
handled from outside your library, BaseException is a really poor name.
Why not name it after the API or framework? That way, it's immediately
obvious where the exception comes from when you're reading client code.
For example, JavaMail throws MessagingException, and the java.io package
throws IOException as a base class for their respective exceptions. You
are thinking as a library implementor instead of a library user, and
threatening to create a mess for your users.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Rizwan]

then it would be MITBaseException (MIT being the software product name which
we are creating). But then I have to include MIT with other exception name
as well for example MITPermissionException, etc.

 

[Chris Smith]

then it would be MITBaseException (MIT being the software product name which
we are creating). But then I have to include MIT with other exception name
as well for example MITPermissionException, etc.

That's the basic idea. I'd suggest MITException as opposed to
MITBaseException. The "base" is still an implementation word, and just
grates a bit when used from a client. The client shouldn't care if it's
a "base" for some other exception; only if it's the exception the client
is interested in. As for "MITPermissionException", that's probably a
good idea just because "permission" is so vague. For a less vague word,
it might not be necessary; for example, FileNotFoundException is not
called IOFileNotFoundException, because the name is descriptive enough.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Rizwan]

the reason of using base is because I was thinking to define it as an
abstract class.

 

[Chris Smith]

the reason of using base is because I was thinking to define it as an
abstract class.

I don't see why it would matter to me, if I'm writing code to use your
library, whether the exception class is abstract or not, just as it
doesn't matter whether it's a base class or not. In either case, when I
want to catch all exceptions thrown by your framework, the code and
purpose is the same and it makes more sense to catch MITException, not
MITBaseException.

Remember what inheritance is: it expresses an "is a" relationship; basic
first-level programming course stuff. When you insist on putting base
in the name, you're causing discongruency for someone who writes:

...
catch (MITBaseException e)
{
...
}

The exception being caught isn't a "base" exception. It's a quite
specific exception, perhaps relating to permissions or structure. Your
code reads wrong.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation