Building an Exception Layer  
Author Message
Rizwan





PostPosted: 2004-11-3 2:00:00 Top

java-programmer, Building an Exception Layer 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





PostPosted: 2004-11-3 5:31:00 Top

java-programmer >> Building an Exception Layer what i can think of is that PermissionException and BusinessRulesException
inherites from Exception while StructureException and DAOException inherites
from RuntimeException.

"Rizwan" <email***@***.com> wrote in message
news:aYPhd.10736$email***@***.com...
> 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
>
>


 
iamfractal





PostPosted: 2004-11-3 20:50:00 Top

java-programmer >> Building an Exception Layer "Rizwan" <email***@***.com> wrote in message news:<Y1Thd.12917$email***@***.com>...
> what i can think of is that PermissionException and BusinessRulesException
> inherites from Exception while StructureException and DAOException inherites
> from RuntimeException.
>
> "Rizwan" <email***@***.com> wrote in message
> news:aYPhd.10736$email***@***.com...
> > 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
> >
> >

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





PostPosted: 2004-11-4 0:10:00 Top

java-programmer >> Building an Exception Layer ok so all four exceptions has to be inherited from BaseException. thanks

<email***@***.com> wrote in message
news:email***@***.com...
> "Rizwan" <email***@***.com> wrote in message
news:<Y1Thd.12917$email***@***.com>...
> > what i can think of is that PermissionException and
BusinessRulesException
> > inherites from Exception while StructureException and DAOException
inherites
> > from RuntimeException.
> >
> > "Rizwan" <email***@***.com> wrote in message
> > news:aYPhd.10736$email***@***.com...
> > > 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
> > >
> > >
>
> 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


 
 
Chris Smith





PostPosted: 2004-11-4 23:35:00 Top

java-programmer >> Building an Exception Layer Rizwan wrote:
> 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





PostPosted: 2004-11-5 0:16:00 Top

java-programmer >> Building an Exception Layer 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" <email***@***.com> wrote in message
news:email***@***.com...
> Rizwan wrote:
> > 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


 
 
Chris Smith





PostPosted: 2004-11-5 5:04:00 Top

java-programmer >> Building an Exception Layer Rizwan wrote:
> 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





PostPosted: 2004-11-6 1:04:00 Top

java-programmer >> Building an Exception Layer the reason of using base is because I was thinking to define it as an
abstract class.

"Chris Smith" <email***@***.com> wrote in message
news:email***@***.com...
> Rizwan wrote:
> > 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


 
 
Chris Smith





PostPosted: 2004-11-6 5:03:00 Top

java-programmer >> Building an Exception Layer Rizwan wrote:
> 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