You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-java@ibatis.apache.org by Bhaarat Sharma <bh...@gmail.com> on 2009/07/31 00:06:16 UTC

how to do error handling?

Hi guys,
I have a few questions on how to handle errors that are thrown when iBatis
calls the Stored Procedures.

Assuming i have the following code:

results_list = getSqlMapClientTemplate().queryForList("spfile.getReport",
parmMap);

If i have the above code then when error occurs, we see it on the screen and
it looks very ugly. Also, if the error occurs in above line then code after
this line is not executed.  I wish to catch the error, put it in the log
file and show user a page that something bad has happened.

So I changed the above code to:
        try {
            results_list =
getSqlMapClientTemplate().queryForList("spfile.getReport", parmMap);
        }
        catch (Exception e)
        {
            log.error(e.getMessage());
        }

this catches the error fine. BUT the problem is that, since I am catch the
error, the code after the above call is also being executed.  Which I do not
want.  If the error occurs in the above call then I don't want any further
code to get executed.  We are implementing error handling at a later stage
in the application.  It would have been better if the code written after the
above call actually checked if something exists in results_list.  But that
is not the case and it would be a pain to change all the code to suit this
need now.

How can I do this?

Re: how to do error handling?

Posted by Bhaarat Sharma <bh...@gmail.com>.
thanks for the reply.
But this is in a DAO method.  the object is returned back to the action
class.  if the object returned is null and we are performing methods on that
object then we will get null pointer exception.

Which, I guess is ok.  But DB message will be logged and then again some
null pointer exception will also be logged.  Which can get confusing?

On Thu, Jul 30, 2009 at 6:13 PM, Larry Meadors <la...@gmail.com>wrote:

> Put all the code you don't want to execute in the try block.
>
> Larry
>
>
> On Thu, Jul 30, 2009 at 4:06 PM, Bhaarat Sharma<bh...@gmail.com>
> wrote:
> > Hi guys,
> > I have a few questions on how to handle errors that are thrown when
> iBatis
> > calls the Stored Procedures.
> > Assuming i have the following code:
> > results_list = getSqlMapClientTemplate().queryForList("spfile.getReport",
> > parmMap);
> > If i have the above code then when error occurs, we see it on the screen
> and
> > it looks very ugly. Also, if the error occurs in above line then code
> after
> > this line is not executed.  I wish to catch the error, put it in the log
> > file and show user a page that something bad has happened.
> > So I changed the above code to:
> >         try {
> >             results_list =
> > getSqlMapClientTemplate().queryForList("spfile.getReport", parmMap);
> >         }
> >         catch (Exception e)
> >         {
> >             log.error(e.getMessage());
> >         }
> > this catches the error fine. BUT the problem is that, since I am catch
> the
> > error, the code after the above call is also being executed.  Which I do
> not
> > want.  If the error occurs in the above call then I don't want any
> further
> > code to get executed.  We are implementing error handling at a later
> stage
> > in the application.  It would have been better if the code written after
> the
> > above call actually checked if something exists in results_list.  But
> that
> > is not the case and it would be a pain to change all the code to suit
> this
> > need now.
> > How can I do this?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> For additional commands, e-mail: user-java-help@ibatis.apache.org
>
>

Re: how to do error handling?

Posted by Larry Meadors <la...@gmail.com>.
Put all the code you don't want to execute in the try block.

Larry


On Thu, Jul 30, 2009 at 4:06 PM, Bhaarat Sharma<bh...@gmail.com> wrote:
> Hi guys,
> I have a few questions on how to handle errors that are thrown when iBatis
> calls the Stored Procedures.
> Assuming i have the following code:
> results_list = getSqlMapClientTemplate().queryForList("spfile.getReport",
> parmMap);
> If i have the above code then when error occurs, we see it on the screen and
> it looks very ugly. Also, if the error occurs in above line then code after
> this line is not executed.  I wish to catch the error, put it in the log
> file and show user a page that something bad has happened.
> So I changed the above code to:
>         try {
>             results_list =
> getSqlMapClientTemplate().queryForList("spfile.getReport", parmMap);
>         }
>         catch (Exception e)
>         {
>             log.error(e.getMessage());
>         }
> this catches the error fine. BUT the problem is that, since I am catch the
> error, the code after the above call is also being executed.  Which I do not
> want.  If the error occurs in the above call then I don't want any further
> code to get executed.  We are implementing error handling at a later stage
> in the application.  It would have been better if the code written after the
> above call actually checked if something exists in results_list.  But that
> is not the case and it would be a pain to change all the code to suit this
> need now.
> How can I do this?

---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org


Re: how to do error handling?

Posted by Nail Uenlue <na...@gmail.com>.
I dont know how you designed your Service layer but putting the
business logic into
some struts classes doesnt seem right to me ;-)

You should follow the POJO way...meaning that you should have a _real_
service layer
which could look like:


MyService.java
------------------------

public class MyService extends MyCommonService{

    public MyDTO getMyObject(String action){
             MyDao myD = new MyDao();
             return myD.getMyDTO();
    }


}


MyDao.java
------------------

public class MyDao extends MyCommonDao{

      public MyDTO getMyDTO(String .....){
          return getSqlMapClientTemplate().queryForList("ibaits.map",
searchString);
      }
}


Your action can then call the Service Class...now..what is the benefit
of this? You didnt
embed your service code into an action where it can _ONLY_ be used in
a struts context.
If two months later your manager asks you to have a web service with
the same information
as on the web frontend delivered to another consumer, you just
generate the webservice stub
and you're ready to go....lose coupling is the key here ;-)

Dont forget that Struts is just a facade to your service backend...it
could be a desktop frontend or
a webservice or...or...or... you get my point.

I dont know struts in detail but from the documentation i found the
following information:

http://struts.apache.org/2.x/docs/exception-configuration.html

There's a good description how to handle runtime exceptions centrally
in case of struts2 ;-)

Just never forget that the key with exception handling is " throw
early, catch late". Means
that you should really try to catch those nasty runtime exception as
late as possible.

Cheers,
Nail

On Fri, Jul 31, 2009 at 12:42 AM, Bhaarat Sharma<bh...@gmail.com> wrote:
> thanks for your explained answer.
> Just to make sure. So you are suggesting that catching the exception at DAO
> level is of no use and I should catch the exception at my action class level
> ( I am using struts2).  So that way, user will only see some generic message
> like 'something happened' but message logged in logs will be something
> related to DB.
> regarding null pointer exception.  This is my sample code in DAO
>     public Object[] getIResults(String action) {
>         Object[] results = new Object[2];
>         HashMap parmMap = new HashMap();
>         parmMap.put("action", action);
>         List results_list = new ArrayList();
>             results_list =
> getSqlMapClientTemplate().queryForList("spfile.getReport", parmMap);
>         if (!results_list.isEmpty()) {
>             results[0] = (List) results_list.get(0);
>             results[1] = (List) results_list.get(1);
>         }
>         return results;
>     }
> The action class uses the Object[] to show the data to the user.  is this an
> OK practice to do this way?
> So I will be putting try/catch block in action class when the DAO method is
> called.
> On Thu, Jul 30, 2009 at 6:29 PM, Nail Uenlue <na...@gmail.com> wrote:
>>
>> Hello,
>>
>> One solution is to put all the code you dont want to execute into the
>> try/catch...but i think
>> that you're trying to follow a wrong concept ...
>>
>> The getSqlMapClientTemplate is from the Spring class DAO support class
>> and Spring
>> is wrapping the SQLException to a DataAccessException and making them an
>> unchecked exception which is 100% correct in my point of view...
>>
>> What can you do when you catch  a SQLException from the DB? Does the
>> developer
>> that catches this exception really know what to do with it? Can he
>> recover from such a
>> situation at runtime? He cant in 99% of the cases....so dont even
>> bother catching those
>> exception at DAO level and let them get all the way up to your so
>> called Exception Barrier,
>> which you can configure at web layer (like the error-page directive in
>> the web.xml) and show
>> a generic message like "A technical problem occured"...
>>
>> Most of the ppl will say that they need more information but a DB
>> exception can mostly not be
>> translated to a meaningful message to the user...
>>
>> And no....your DAO method should never return a null value....why do
>> you try to provoke NullPointerExceptions?
>> You better let the exception go up as a unchecked exception and handle
>> it in your
>> Exception barrier..
>>
>>
>> On Fri, Jul 31, 2009 at 12:06 AM, Bhaarat Sharma<bh...@gmail.com>
>> wrote:
>> > Hi guys,
>> > I have a few questions on how to handle errors that are thrown when
>> > iBatis
>> > calls the Stored Procedures.
>> > Assuming i have the following code:
>> > results_list =
>> > getSqlMapClientTemplate().queryForList("spfile.getReport",
>> > parmMap);
>> > If i have the above code then when error occurs, we see it on the screen
>> > and
>> > it looks very ugly. Also, if the error occurs in above line then code
>> > after
>> > this line is not executed.  I wish to catch the error, put it in the log
>> > file and show user a page that something bad has happened.
>> > So I changed the above code to:
>> >         try {
>> >             results_list =
>> > getSqlMapClientTemplate().queryForList("spfile.getReport", parmMap);
>> >         }
>> >         catch (Exception e)
>> >         {
>> >             log.error(e.getMessage());
>> >         }
>> > this catches the error fine. BUT the problem is that, since I am catch
>> > the
>> > error, the code after the above call is also being executed.  Which I do
>> > not
>> > want.  If the error occurs in the above call then I don't want any
>> > further
>> > code to get executed.  We are implementing error handling at a later
>> > stage
>> > in the application.  It would have been better if the code written after
>> > the
>> > above call actually checked if something exists in results_list.  But
>> > that
>> > is not the case and it would be a pain to change all the code to suit
>> > this
>> > need now.
>> > How can I do this?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
>> For additional commands, e-mail: user-java-help@ibatis.apache.org
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org


Re: how to do error handling?

Posted by Bhaarat Sharma <bh...@gmail.com>.
thanks for your explained answer.
Just to make sure. So you are suggesting that catching the exception at DAO
level is of no use and I should catch the exception at my action class level
( I am using struts2).  So that way, user will only see some generic message
like 'something happened' but message logged in logs will be something
related to DB.

regarding null pointer exception.  This is my sample code in DAO

    public Object[] getIResults(String action) {
        Object[] results = new Object[2];
        HashMap parmMap = new HashMap();
        parmMap.put("action", action);
        List results_list = new ArrayList();
            results_list =
getSqlMapClientTemplate().queryForList("spfile.getReport", parmMap);
        if (!results_list.isEmpty()) {
            results[0] = (List) results_list.get(0);
            results[1] = (List) results_list.get(1);
        }
        return results;
    }

The action class uses the Object[] to show the data to the user.  is this an
OK practice to do this way?

So I will be putting try/catch block in action class when the DAO method is
called.

On Thu, Jul 30, 2009 at 6:29 PM, Nail Uenlue <na...@gmail.com> wrote:

> Hello,
>
> One solution is to put all the code you dont want to execute into the
> try/catch...but i think
> that you're trying to follow a wrong concept ...
>
> The getSqlMapClientTemplate is from the Spring class DAO support class
> and Spring
> is wrapping the SQLException to a DataAccessException and making them an
> unchecked exception which is 100% correct in my point of view...
>
> What can you do when you catch  a SQLException from the DB? Does the
> developer
> that catches this exception really know what to do with it? Can he
> recover from such a
> situation at runtime? He cant in 99% of the cases....so dont even
> bother catching those
> exception at DAO level and let them get all the way up to your so
> called Exception Barrier,
> which you can configure at web layer (like the error-page directive in
> the web.xml) and show
> a generic message like "A technical problem occured"...
>
> Most of the ppl will say that they need more information but a DB
> exception can mostly not be
> translated to a meaningful message to the user...
>
> And no....your DAO method should never return a null value....why do
> you try to provoke NullPointerExceptions?
> You better let the exception go up as a unchecked exception and handle
> it in your
> Exception barrier..
>
>
> On Fri, Jul 31, 2009 at 12:06 AM, Bhaarat Sharma<bh...@gmail.com>
> wrote:
> > Hi guys,
> > I have a few questions on how to handle errors that are thrown when
> iBatis
> > calls the Stored Procedures.
> > Assuming i have the following code:
> > results_list = getSqlMapClientTemplate().queryForList("spfile.getReport",
> > parmMap);
> > If i have the above code then when error occurs, we see it on the screen
> and
> > it looks very ugly. Also, if the error occurs in above line then code
> after
> > this line is not executed.  I wish to catch the error, put it in the log
> > file and show user a page that something bad has happened.
> > So I changed the above code to:
> >         try {
> >             results_list =
> > getSqlMapClientTemplate().queryForList("spfile.getReport", parmMap);
> >         }
> >         catch (Exception e)
> >         {
> >             log.error(e.getMessage());
> >         }
> > this catches the error fine. BUT the problem is that, since I am catch
> the
> > error, the code after the above call is also being executed.  Which I do
> not
> > want.  If the error occurs in the above call then I don't want any
> further
> > code to get executed.  We are implementing error handling at a later
> stage
> > in the application.  It would have been better if the code written after
> the
> > above call actually checked if something exists in results_list.  But
> that
> > is not the case and it would be a pain to change all the code to suit
> this
> > need now.
> > How can I do this?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> For additional commands, e-mail: user-java-help@ibatis.apache.org
>
>

Re: how to do error handling?

Posted by Nail Uenlue <na...@gmail.com>.
Hello,

One solution is to put all the code you dont want to execute into the
try/catch...but i think
that you're trying to follow a wrong concept ...

The getSqlMapClientTemplate is from the Spring class DAO support class
and Spring
is wrapping the SQLException to a DataAccessException and making them an
unchecked exception which is 100% correct in my point of view...

What can you do when you catch  a SQLException from the DB? Does the developer
that catches this exception really know what to do with it? Can he
recover from such a
situation at runtime? He cant in 99% of the cases....so dont even
bother catching those
exception at DAO level and let them get all the way up to your so
called Exception Barrier,
which you can configure at web layer (like the error-page directive in
the web.xml) and show
a generic message like "A technical problem occured"...

Most of the ppl will say that they need more information but a DB
exception can mostly not be
translated to a meaningful message to the user...

And no....your DAO method should never return a null value....why do
you try to provoke NullPointerExceptions?
You better let the exception go up as a unchecked exception and handle
it in your
Exception barrier..


On Fri, Jul 31, 2009 at 12:06 AM, Bhaarat Sharma<bh...@gmail.com> wrote:
> Hi guys,
> I have a few questions on how to handle errors that are thrown when iBatis
> calls the Stored Procedures.
> Assuming i have the following code:
> results_list = getSqlMapClientTemplate().queryForList("spfile.getReport",
> parmMap);
> If i have the above code then when error occurs, we see it on the screen and
> it looks very ugly. Also, if the error occurs in above line then code after
> this line is not executed.  I wish to catch the error, put it in the log
> file and show user a page that something bad has happened.
> So I changed the above code to:
>         try {
>             results_list =
> getSqlMapClientTemplate().queryForList("spfile.getReport", parmMap);
>         }
>         catch (Exception e)
>         {
>             log.error(e.getMessage());
>         }
> this catches the error fine. BUT the problem is that, since I am catch the
> error, the code after the above call is also being executed.  Which I do not
> want.  If the error occurs in the above call then I don't want any further
> code to get executed.  We are implementing error handling at a later stage
> in the application.  It would have been better if the code written after the
> above call actually checked if something exists in results_list.  But that
> is not the case and it would be a pain to change all the code to suit this
> need now.
> How can I do this?

---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org