Path: csiph.com!usenet.pasdenom.info!news.albasani.net!.POSTED!not-for-mail From: Lew Newsgroups: comp.lang.java.programmer Subject: Re: Quick Error Handling Question Date: Mon, 05 Mar 2012 02:48:58 -0800 Organization: albasani.net Lines: 38 Message-ID: References: <4f541549$0$293$14726298@news.sunsite.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: news.albasani.net xE8ZTAjXXisHl276fBZG+ebAVutxoqF8Dcf0ohJ2p8ERywoIX6q19+5dDHiHO8JsyC5PzvMt2baj59hYnrics7sTljbcQoqJGL916CCqcMbRrZ+/PVSSK04uUpSgCSA1 NNTP-Posting-Date: Mon, 5 Mar 2012 10:48:54 +0000 (UTC) Injection-Info: news.albasani.net; logging-data="yli5vvwWUF9x02xogp52TPpcxH9/ZSmfytMM1FTcjSbLc7ve1XRLopKmQtWKLr2wvtpNj4Pr66uMfhEIpiNxsghCU0tVohMsNrX9luejYpaE60nkOdJJU1Xi4cBz4HcY"; mail-complaints-to="abuse@albasani.net" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 In-Reply-To: <4f541549$0$293$14726298@news.sunsite.dk> Cancel-Lock: sha1:/I4ZcAPrHzZeQS+zAjt+4jT8oOI= Xref: csiph.com comp.lang.java.programmer:12706 Arne Vajhøj wrote: > Novice wrote: >> I'm trying to learn more about Error Handling. I've read the Java Tutorial >> topic on it, as well as Bloch's Effective Java (2nd edition) tips on it. >> I've started on Robust Java by Stephen Stelting too. I know I'm going to >> have more questions later but one is bugging me right now and I'm not >> seeing it mentioned anywhere so let me ask now. >> >> 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? > > In general I don't like multi line log messages, but stacktraces > are just too damn useful, so I would say log them anyway. This is where you use log levels. Log headlines at "error" level (SEVERE or ERROR depending on library). Think about what's appropriate for stack traces case by case. I usually log the trace at "debug" (FINE or DEBUG), but there isn't exactly a recipe. In case of trouble, the installation can play with log levels to open the information floodgates in relevant areas, then shut them off again after diagnostics. There is a principle, elucidated for you the other day. Logs are for troubleshooting. Make them useful for people when they're troubleshooting. Not for you just when you're developing, not for prettiness, not for confusion. Read your own log files and see what they tell you. Try them at different levels. Write unit tests that crash your code and see what's logged. Make them useful. Arne's suggestion is wise - when you need a stack trace and it isn't there, what now? Conversely, when you don't need it and it's there, what harm? (I say there is some - but how much?) If it's configurable in the field and you can get traces or not at will, how about that? -- Lew Honi soit qui mal y pense. http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg