Path: csiph.com!usenet.pasdenom.info!news.albasani.net!.POSTED!not-for-mail From: Lew Newsgroups: comp.lang.java.programmer Subject: Re: Exception Handling Date: Tue, 13 Mar 2012 08:31:46 -0700 Organization: albasani.net Lines: 102 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.albasani.net xeEQ7dB4WQWAalZUgNEC6fbyh6KXNQjtghJ7wwSk6/MFprM2rmicEVsHA5qh1iHi/mxxAKRDopKX+pQRP8Rkxr61Csc77SRWTJjJwPBXMiyZ/Rj//sUKckL8/B55cJ9Q NNTP-Posting-Date: Tue, 13 Mar 2012 15:31:49 +0000 (UTC) Injection-Info: news.albasani.net; logging-data="Mfh9/O6+e3TuEEl+aNc5LRsk5V3iMF47rkp5OwIcbUtRt8DgqyQi/O9fjgz/uYhBTaGdpJcnnT+V4fEmvhaklUEsp0bRXDvoe1lt0Sdgy/wlVVNLl75NDLXNBryULSds"; 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: Cancel-Lock: sha1:6rj1vx3w44FFpX9RlaljBnKcAeU= Xref: csiph.com comp.lang.java.programmer:12956 Novice wrote: > Are you envisioning that our hypothetical Foo would have a single > FooException that it wraps around everything that percolates up from the > lower levels? Or would there be a bunch of FooExceptions, each handling > different sorts of problems? Quite often a single exception type suffices. You would only add another if there were a crying need for it. > And what happens with logging? Do we just log the error as an > IllegalArgumentException (or whatever) when we find it at the low level? Did you read Patricia's advice on this very matter? > Or do we also log it again, this time as a FooException, when we deal > with it at the higher levels? I'm uneasy about writing what are > effectively redundant messages to the log. Patricia recommended, and I agree, that the custom exception serve as a signal that the lower-level problem has been logged. Remember? > For what it's worth, I've cobbled together a CrashDialog class which my > higher level methods, getLocalizedText() for example, displays when it > handles an IllegalArgumentException() if it is thrown by getResources(). > (I'm now throwing IllegalArgumentException for nulls in the parameters as > well as a failed getBundle()). In that case, the CrashDialog class says: Is a failed 'getBundle()' really a programming error? Is it really an illegal argument? There was nothing illegal about the argument /per se/ if the resource just happened not to be available. I suggest a checked exception, either 'IOException' or a subtype thereof, for a missing bundle, unless it really and truly is completely under programmer control. (And deployment-time issues never are.) > =================================================================== > Foo - Severe Error > > The program has to stop for the following reason: Certain language > resources were not available. > > The problem has been logged and Technical Support will begin resolving > the error shortly. > > [Okay] > ==================================================================== > > The line about Technical Support resolving the problem shortly is > somewhat fanciful since I'm the whole development team and the entire > universe of end users at the moment ;-) I'm just envisioning what I'd say > in a real production application. Be careful of making promises because you must keep them. Well, technically you don't have to, but do you want to be that guy? > The bit about the language resources being unavailable is not completely > satisfactory because it is probably not very helpful to a non-technical > user but it seemed better to summarize the situation than to use the > message from the exception; the user is even less likely to comprehend > "the baseName must not be null" or "Unable to find resources for base > name, com.novice.foo.FooTextzzz, and locale, jp_JP. Check the spelling of > the base name". And I certainly don't want to display a stacktrace to the > user! > > I've also logged the fact that the user clicked on okay to end the > program as another SEVERE error. Mind you, that seems redundant and I'm How is that any kind of error? > inclined to remove that code again. I'm assuming that in the real world, > one SEVERE error is going to be enough to get the attention of the > appropriate people and producing two or three SEVERE errors about the > same problem is not going to get the problem examined any sooner. Correct > me if I'm wrong! Don't worry, we will. But you have a brain. What makes sense there? What would look funny to the ops guy? Are you really thinking like a troubleshooter in the field, or like the programmer whose name that troubleshooter will curse? > Now, that behavior wouldn't be standard for all cases. If the error is > recoverable, the user would get different instructions that would lead > him/her through whatever needs to be done to recover. And some errors > might not be severe at all and just be informational. In those cases, the > dialog might say "Information" instead of Severe Error and simply > describe whatever workaround Foo adopted to get past the problem. > > I'm feeling good about the error handling and logging now. It's starting > to fall into place for me, aside from the whole custom exception > question. What do you mean by "recoverable"? I mean able to show an error dialog and invite the operator to shut down. Is that not a valid program state? -- Lew Honi soit qui mal y pense. http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg