Building an Exception Layer

Discussion in 'Java' started by Rizwan, Nov 2, 2004.

  1. Rizwan

    Rizwan Guest

    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, Nov 2, 2004
    #1
    1. Advertising

  2. Rizwan

    Rizwan Guest

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

    "Rizwan" <> wrote in message
    news:aYPhd.10736$...
    > 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, Nov 2, 2004
    #2
    1. Advertising

  3. Rizwan

    Guest

    "Rizwan" <> wrote in message news:<Y1Thd.12917$>...
    > what i can think of is that PermissionException and BusinessRulesException
    > inherites from Exception while StructureException and DAOException inherites
    > from RuntimeException.
    >
    > "Rizwan" <> wrote in message
    > news:aYPhd.10736$...
    > > 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
     
    , Nov 3, 2004
    #3
  4. Rizwan

    Rizwan Guest

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

    <> wrote in message
    news:...
    > "Rizwan" <> wrote in message

    news:<Y1Thd.12917$>...
    > > what i can think of is that PermissionException and

    BusinessRulesException
    > > inherites from Exception while StructureException and DAOException

    inherites
    > > from RuntimeException.
    > >
    > > "Rizwan" <> wrote in message
    > > news:aYPhd.10736$...
    > > > 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, Nov 3, 2004
    #4
  5. Rizwan

    Chris Smith Guest

    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, Nov 4, 2004
    #5
  6. Rizwan

    Rizwan Guest

    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" <> wrote in message
    news:...
    > 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, Nov 4, 2004
    #6
  7. Rizwan

    Chris Smith Guest

    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, Nov 4, 2004
    #7
  8. Rizwan

    Rizwan Guest

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

    "Chris Smith" <> wrote in message
    news:...
    > 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, Nov 5, 2004
    #8
  9. Rizwan

    Chris Smith Guest

    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
     
    Chris Smith, Nov 5, 2004
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?YzY3NjIyOA==?=

    do it in database layer or application layer

    =?Utf-8?B?YzY3NjIyOA==?=, Jan 26, 2006, in forum: ASP .Net
    Replies:
    3
    Views:
    435
    Karl Seguin [MVP]
    Jan 27, 2006
  2. et
    Replies:
    2
    Views:
    1,921
  3. dan
    Replies:
    25
    Views:
    1,339
    Uncle Bob (Robert C. Martin)
    Oct 28, 2003
  4. Universe
    Replies:
    1
    Views:
    477
    Universe
    Oct 24, 2003
  5. Dhananjay
    Replies:
    1
    Views:
    1,127
    sloan
    Dec 18, 2006
Loading...

Share This Page