Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: can't throw Date: Sun, 16 Sep 2012 15:46:44 +0200 Lines: 67 Message-ID: References: <19af6b94-7a1e-4491-afb2-79782406f560@googlegroups.com> <504fe3a6$0$293$14726298@news.sunsite.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net yAXZ5efA0mqN14tV5UnunQQLWZs3h900RzdafteQcqB2487y+SzN22tTh7CubPocE= Cancel-Lock: sha1:jeTVBTswyS4ONjZhhqwwLW3tMTA= User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0 In-Reply-To: Xref: csiph.com comp.lang.java.programmer:18790 On 09/15/2012 12:33 AM, Leif Roar Moldskred wrote: > Personally, I think it was a design flaw to tie the checked / > unchecked to the class hierarchy. An exception's class corresponds to > a particular error type, but the severity of a particular type of > error, and wheter we can expect the client to be able to recover from > it or not, depends on the context. > > The choice of checked / unchecked should be made statically _at the > point of the throw statement_, Let's see what the consequences of this would be: 1. we need new syntax (e.g. a new keyword), in order to make that distinction. So it's either throw checked new IllegalStateException("You can't do that right now.") throw_checked new IllegalStateException("You can't do that right now.") 2. The complier needs to enforce all exceptions thrown with "throw checked" are declared in the throws clause. OK so far, no issues there. 3. Now, assume we have a section of code which throws the same exception type checked and unchecked. That section is embedded in a try block. Now we have a catch clause for this exception type attached to the try block. This prompts the question: which of the thrown exceptions does the catch block handle - only the checked throws or also unchecked throws? 3a. It handles both. This leads to the unsatisfactory situation where the same catch block needs to handle programmer errors (now RuntimeException and subclasses) and other errors which are actually expected. That's not good since programmer errors (and catastrophic situations like OOM are usually handled quite close to Thread.run, i.e. further up the call stack. 3b. The programmer can decide, so we need a new syntax again: catch checked ( IllegalStateException e ) This will only catch checked exceptions. Do we now need an additional syntax for "unchecked", e.g. catch unchecked ( IllegalStateException e ) And what do we do if we want to cover both cases (e.g. because we just want to print the error)? Do we then do this? catch checked, unchecked ( IllegalStateException e ) Or do we use the current form to mean "catch both"? catch ( IllegalStateException e ) In which way we resolve these questions it's obvious that one can easily forget a keyword or make a different error so one ends handling other exceptions than intended. Given the fact that the type of exception also describes the type of error and that in turn is related to the classification "programmer error" / "no programmer error" I am not so sure whether the additional complication your distinction at call site introduces is actually worthwhile. Kind regards robert