Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!eternal-september.org!feeder.eternal-september.org!feeds.phibee-telecom.net!usenet.ukfsn.org!not-for-mail From: Martin Gregorie Newsgroups: comp.lang.java.programmer Subject: Re: Quick Error Handling Question Date: Tue, 6 Mar 2012 00:01:42 +0000 (UTC) Organization: UK Free Software Network Lines: 51 Message-ID: References: <4f541e87$0$294$14726298@news.sunsite.dk> NNTP-Posting-Host: 84.45.235.129 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: localhost.localdomain 1330992102 27371 84.45.235.129 (6 Mar 2012 00:01:42 GMT) X-Complaints-To: usenet@localhost.localdomain NNTP-Posting-Date: Tue, 6 Mar 2012 00:01:42 +0000 (UTC) User-Agent: Pan/0.135 (Tomorrow I'll Wake Up and Scald Myself with Tea; GIT 30dc37b master) Xref: csiph.com comp.lang.java.programmer:12726 On Mon, 05 Mar 2012 19:55:08 -0400, Arved Sandstrom wrote: > On 12-03-05 06:59 PM, Martin Gregorie wrote: >> On Sun, 04 Mar 2012 21:01:42 -0500, Arne Vajhøj wrote: >> >>> On 3/4/2012 8:26 PM, Stefan Ram wrote: >>>> Novice writes: >>>>> Should I write stacktraces from my checked and unchecked exceptions >>>>> to my log? Or just assume that all stacktraces will be written to >>>>> the console and the console will always be accessible to everyone >>>>> who needs it? >>>> >>>> When an exception is checked, it usually will be handled by code >>>> that knows how to deal with it and, insofar, »has expected« it. >>>> So, >>>> often, >>>> there is no need to log all details or to log anything at all. >>> >>> I am a bit skeptical about the idea of checked exceptions being dealt >>> with and therefore no details being necessary. >>> >>> You may catch a SQLException and be able to get the data right in the >>> database, but you may still want to know why it failed in the first >>> place. If it happens too frequently it may require corrective action. >>> >> IMO the SQL Exception is the one case where a single line is almost >> never enough. I'd say its always necessary to work your way down the >> SQLException chain outputing the contents of all of them and, depending >> in the program's structure and logic, it is often a good idea to add >> the query's text as well[1]. >> >> Assuming, of course, that you're using traditional SQL statements >> rather than some JPA. >> > Can't speak to other JPA implementations, but with EclipseLink logging > you get potentially a multitude of information. Query text and bind > parameters are already available at FINE, and there's still FINER and > FINEST. > > JPA is also well provided with its own exception classes: there are ten > or so subclasses of javax.persistence.PersistenceException. If something > underneath at the JDBC level throws a java.sql.SQLException you'll see > that too. > Good to know. I was only excepting due to lack of experience with them. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |