Return-Path: Delivered-To: apmail-ibatis-user-java-archive@www.apache.org Received: (qmail 26144 invoked from network); 30 Jul 2009 22:30:08 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 30 Jul 2009 22:30:08 -0000 Received: (qmail 31382 invoked by uid 500); 30 Jul 2009 22:30:08 -0000 Delivered-To: apmail-ibatis-user-java-archive@ibatis.apache.org Received: (qmail 31362 invoked by uid 500); 30 Jul 2009 22:30:08 -0000 Mailing-List: contact user-java-help@ibatis.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user-java@ibatis.apache.org Delivered-To: mailing list user-java@ibatis.apache.org Received: (qmail 31354 invoked by uid 99); 30 Jul 2009 22:30:08 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 30 Jul 2009 22:30:08 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of nail.uenlue@gmail.com designates 209.85.218.208 as permitted sender) Received: from [209.85.218.208] (HELO mail-bw0-f208.google.com) (209.85.218.208) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 30 Jul 2009 22:30:00 +0000 Received: by bwz4 with SMTP id 4so2380509bwz.0 for ; Thu, 30 Jul 2009 15:29:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=rfM8T3MyXPcw5tg7KvbWztrkpWRlViRux00JwYgA/IY=; b=QSFRKogUzm+UqcXwMpIRDrI66MWHg9cisOlAOGojD08Bu77nnJhSK0uIqY7/x96cDf fCd4/stIGBxAc6fpjl7CsBWDwbmqTHIs14Y3stGl/onqyKpHWgxbTZZ0gPoB5eht57Ts Pu7crSRBP9O47R/g3mZB5rakhD3ryz4P9om08= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=WiDL21V653kgZmxYD9WJnzs/GC6ThH2DzlIzjOvAqWVbGxwGZ5FM75rdEs4ha2iJiX NH96b9K2DNfKc7iUaefEN5/gKG/mKVnAjfAM2JEg5Gx09XFnyGRkLCGSr5WE71CQTPof 4OwaouwjmksXXjMO7zAtiAsfsejGW8SOJssX4= MIME-Version: 1.0 Received: by 10.204.50.212 with SMTP id a20mr612993bkg.35.1248992978439; Thu, 30 Jul 2009 15:29:38 -0700 (PDT) In-Reply-To: <491bd2b50907301506l450ec366ufcbfa5937799b1bf@mail.gmail.com> References: <491bd2b50907301506l450ec366ufcbfa5937799b1bf@mail.gmail.com> Date: Fri, 31 Jul 2009 00:29:38 +0200 Message-ID: <286f94a70907301529o601986c1s3638ed6f97bed289@mail.gmail.com> Subject: Re: how to do error handling? From: Nail Uenlue To: user-java@ibatis.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org 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 develo= per 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 wrote= : > Hi guys, > I have a few questions on how to handle errors that are thrown when iBati= s > calls the Stored Procedures. > Assuming i have the following code: > results_list =3D 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 aft= er > this line is not executed. =A0I wish to catch the error, put it in the lo= g > file and show user a page that something bad has happened. > So I changed the above code to: > =A0=A0 =A0 =A0 =A0try { > =A0=A0 =A0 =A0 =A0 =A0 =A0results_list =3D > getSqlMapClientTemplate().queryForList("spfile.getReport", parmMap); > =A0=A0 =A0 =A0 =A0} > =A0=A0 =A0 =A0 =A0catch (Exception e) > =A0=A0 =A0 =A0 =A0{ > =A0=A0 =A0 =A0 =A0 =A0 =A0log.error(e.getMessage()); > =A0=A0 =A0 =A0 =A0} > this catches the error fine. BUT the problem is that, since I am catch th= e > error, the code after the above call is also being executed. =A0Which I d= o not > want. =A0If the error occurs in the above call then I=A0don't=A0want any = further > code to get executed. =A0We are implementing error handling at a later st= age > in the application. =A0It would have been better if the code written afte= r the > above call actually checked if something exists in results_list. =A0But t= hat > is not the case and it would be a pain to change all the code to suit thi= s > 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