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<bhaara...@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-unsubscr...@ibatis.apache.org
For additional commands, e-mail: user-java-h...@ibatis.apache.org
