Results 1 to 4 of 4
  1. #1
    MarkTwain is offline Member
    Join Date
    Oct 2009
    Posts
    2
    Rep Power
    0

    Default Template Method Pattern

    Hi All,

    I want to implement the template pattern for handling properly the jdbc resources after each query to the database.

    The base class contains an abstract method that should be implemented by the all the subclasses in order to:
    -Perfoming the specific query to the database
    -Building the DTO object from the ResultSet

    The super class's template method calls the abstract method and then release properly all the jdbc resources created during the transaction.

    The signature for the abstract method is the following:

    protected abstract Object executeQuery(Connection jdbcConnection)
    throws SQLException;


    So far, I used Java Bean as DTO and the SQLException is the only exception that could be throw by the implementations of the abstract method.
    Now,I need to use org.w3c.dom.Document class as DTO object.

    That means the implementations of the executeQuery method now could throw exceptions other than SQLException (E.g. ParserConfigurationException)
    So I need to change the signature of my abstract method in order to handle it.

    What I want to know is:
    Which is a good solution to use a template method if you donít which kind of exception can be thrown by the abstract method.
    Should I declare the abstract method in a general way like:

    protected abstract Object executeQuery(Connection jdbcConnection)
    throws DAOException;


    catching all the possible exception in the sub classes and throwing DAOExceptions?

    Thanks in advance,

    Mark

  2. #2
    literallyjer is offline Member
    Join Date
    Oct 2009
    Posts
    25
    Rep Power
    0

    Default

    A good question to ask yourself is: Do I really need to throw these exceptions? Is it possible for me to catch any of them and fix the problem?

    Exceptions are nasty and should really be dealt with if possible, rather then leaving them for someone else to deal with. If you can recover from any of the non-Runtime exceptions, then I suggest you do.
    Last edited by literallyjer; 10-21-2009 at 01:42 AM. Reason: spell check

  3. #3
    MarkTwain is offline Member
    Join Date
    Oct 2009
    Posts
    2
    Rep Power
    0

    Default

    Thanks for your quick answer,

    The SQLException thrown by executeQuery method's implementations need to be handled in the same way. So, in order to avoid to duplicate the code in all sub-classes i let the sub-classes throw SQLException and it is the base class responsible for catching SQLException and handling it properly (in my code throwing a DAOException).

    Below you can find the skeloton of my template method called run:

    public Object run() throws DAOException {
    Object result;
    //Code for Retrieving the connection object
    try {
    result = executeQuery(connection);
    } catch (SQLException sqle) {
    // In case of sql exception here, we log the error
    throw new DAOException(errorMsg, sqle)
    } finally {
    // Releasing all jdbc resources allocated
    }
    return result;
    }


    As you can see, the template method do:
    - Retrieve the connection object.
    - Call the abstract executeQuery method passing the connection object.
    - Handle SQLException coming from executeQuery implemantations
    - Release the jdbc resource whatever happens.

    I agree with you that is better to handle as early as possible exceptions, but in this case is the base-class in charge of handle it, i don't let the exceptions to be thrown to the client code.

    So do you think it is better for the sub-classes to handle all the possible exceptions and then throwing always DAOException?

    Thanks

  4. #4
    literallyjer is offline Member
    Join Date
    Oct 2009
    Posts
    25
    Rep Power
    0

    Default

    Well, I am not really sure what the best practice is here. However, I think that there is an advantage of catching the exceptions and throwing a DAOException for your client code to deal with. This provides encapsulation for when/if you decided to change your backend code. Also, it might be worth while making DAOException extend RuntimeException. Therefore, if in the future the exception is never actually thrown, you never have to worry about catching it. Also, if it is impossible to recover from any of your encapsulated exceptions, then there's no reason to make yourself catch them every time you call executeQuery.

Similar Threads

  1. Template for System.out.println
    By eva in forum Eclipse
    Replies: 3
    Last Post: 01-05-2008, 12:46 PM
  2. SWT code template
    By Java Tip in forum Java Tip
    Replies: 0
    Last Post: 12-30-2007, 12:18 PM
  3. Help with TLD template
    By Albert in forum JavaServer Pages (JSP) and JSTL
    Replies: 1
    Last Post: 07-13-2007, 03:09 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •