-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 6 posts ] 
Author Message
 Post subject: Exceptions catching in DAO
PostPosted: Thu Nov 04, 2004 3:51 pm 
Beginner
Beginner

Joined: Mon Sep 06, 2004 9:36 am
Posts: 35
I have a table MOVIE in my database. I have made Movie class which implements serializable and Movie.hbm.xml.

I have defined 2 exceptions: InfrastructureException (for Hiberante Session Layer) and DAOException (for DAO Layer).

I have build the HibernateSession class in the same way as the caveatemptor example. I am throwing the Infrastructure exception whenever an excpetion is caught in it.

Now I am trying to build a DAO Layer. According to the my understanding MovieDAO should only throw the DAOException but I find out that I have to get the Session and for that I have to catch InfrastructureException. This does not seem right to me. What is the logic? or what I am doing wrong ?

Thanks


Top
 Profile  
 
 Post subject:
PostPosted: Thu Nov 04, 2004 5:07 pm 
Expert
Expert

Joined: Thu Jan 29, 2004 2:31 am
Posts: 362
Location: Switzerland, Bern
What about making the InfrastructureException an unchecked?

HTH
Ernst


Top
 Profile  
 
 Post subject:
PostPosted: Thu Nov 04, 2004 6:00 pm 
Beginner
Beginner

Joined: Mon Sep 06, 2004 9:36 am
Posts: 35
I did not get you. Come again please.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Nov 04, 2004 6:48 pm 
Newbie

Joined: Thu Nov 04, 2004 6:00 pm
Posts: 8
Location: Palo Alto, CA
All exceptions are either checked or unchecked. Checked exceptions must be declared in the throws clause of any method that throws them (or allows them to propagate from another method it calls) while unchecked exceptions do not.

An exception is unchecked if it extends another unchecked exception or extends RuntimeException or Error, the two roots of all unchecked exceptions. Examples include NullPointerException, ArrayIndexOutOfBoundsException and OutOfMemoryError. These are conditions that most normal code will not attempt to catch and handle, except for cases like a servlet container that catches any Throwable and sends back a 500 error to keep the JVM or that worker thread from tanking.

You can find plenty of debate on the merits of using checked vs. unchecked exceptions. For infrastructure and framework code, I lean heavily towards unchecked exceptions. The reason is that your SearchForUser business object can't realistically deal with a DaoException stating that the database is unreachable. Let the exception bubble up to the servlet container.

To bring this back to your question, you can make InfrastructureException unchecked, allowing it to bubble up the call chain from your HibernateSession methods through your DAO layer without having to catch it in the DAO and wrap it in a DaoException, adding no value whatsoever -- just code bloat.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Nov 05, 2004 12:35 pm 
Beginner
Beginner

Joined: Mon Sep 06, 2004 9:36 am
Posts: 35
thanks for explaining. Let me tell you how I have tried to implement your soilution :

I have defined a base exception WFBaseException which extends Exception and then 2 exceptions WFInfrastructureException and WFDAOException are inhereited from it (WF is the initial for the software product I am working on).

In WFInfrastructureException class, I have code like this (for now):
public WFInfrastructureException( Throwable cause, String message ) {
System.out.println( "WFInfrastructureException: " + message );
cause.printStackTrace();
}

In WFDAOException class, I have code like this (for now) :
public WFDAOException( Throwable cause, String message ) {
System.out.println( "WFDAOException: " + message );
cause.printStackTrace();
}
public WFDAOException( String message, Throwable cause ) {
System.out.println( "WFInfrastructureException: " + message );
cause.printStackTrace();
}


In my HibernateSession class , I have code like this :
public static Session getSesstion throws WFInfrastructureException {
try {
...
} catch (HibernateException he) {
throw new WFInfrastructureException( he, he.getMessage() );
}
}

In my MovieDAO class, I have now written code like this :

public Movie createMovieDAO( String id, String name ) throws WFDAOException {
Movie movie;
try {
Session session HibernateSession.getSession( );
...
} catch (WFInfrastructureException ie) {
throw new WFDAOException( ie.getMessage(), ie );
} catch (WFDAOException daoe) {
throw new WFDAOException( daoe, daoe.getMessage() );
}
return movie;
}

As you can see i am now catching the WFInfrastructureException in WFDAOException although i think the way I have written is not right.
There must be a better way to do it. What do you think?

Thanks


Top
 Profile  
 
 Post subject:
PostPosted: Fri Nov 05, 2004 5:08 pm 
Newbie

Joined: Thu Nov 04, 2004 6:00 pm
Posts: 8
Location: Palo Alto, CA
Yes, there is a better way IMHO. Here's how it would look:
  1. WFBaseException extends Exception (same)
  2. WFInfrastructureException extends RuntimeException
  3. WFDAOException extends WFIE (same)
Now, whenever you throw WFIE or WFDAOE, you do not have to declare it in the throws clause (though you can without effect but you should declare it in your JavaDocs if you write them).

Your code would now look like this:
Code:
// HibernateSession:

public static Session getSesstion
{
    try {
        ...
    } catch ( HibernateException he ) {
        throw new WFInfrastructureException(he, he.getMessage());
    }
}

// MovieDAO:

public Movie createMovie ( String id , String name )
{
    Movie movie;
    try {
        Session session HibernateSession.getSession( );
        ...
    } catch ( HibernateException he ) {
        throw new WFDAOException(he, he.getMessage());
    }
    return movie;
}
You were catching and rewrapping WFDAOE with another WFDAOE, but I assume you meant to catch HibernateExceptions thrown by interacting with the session.

The main difference is that now you don't need a bunch of code to wrap exceptions in new exceptions appropriate for each layer. Now the DAO can worry only about exceptions that it causes directly. Those caused by the infrastructure bubble up without intervention.

Yes, you still must be aware that calling the DAO can result in a WFIE, but you can do the same thing: let it bubble up. You only need to do something about it in the few instances where you can, or if your code can add useful contextual meaning.

Here are a few good links from a Google search:


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 6 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.