Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Eric Sosman Newsgroups: comp.lang.java.programmer Subject: Re: Java Checked Exception is BAD! Date: Fri, 5 Feb 2016 08:20:54 -0500 Organization: A noiseless patient Spider Lines: 29 Message-ID: References: <00ab9f4e-0f06-48ec-9a65-1a150c129a39@googlegroups.com> <8565ac8a-e4e2-4178-b4da-7f3a8ef8069d@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Fri, 5 Feb 2016 13:18:17 -0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="2d081e2f7155c28005d4472f67c2f43d"; logging-data="3682"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+HYDGG0GcUuFuOaiYAooMZ" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 In-Reply-To: <8565ac8a-e4e2-4178-b4da-7f3a8ef8069d@googlegroups.com> Cancel-Lock: sha1:YyEE+LqOypJrY35Kxyi+a8Zv9Jg= Xref: csiph.com comp.lang.java.programmer:33614 On 2/4/2016 6:31 PM, boxzou@gmail.com wrote: > [...] > Maybe I was not clear in the blog. I think all problems with Checked Exception arise from the following contradiction: > > 1. Exception should be handled rarely, vs > 2. Exception must be handled (either catch or throws). If code is to be reliable, (1) cannot hold: Exceptional conditions that arise (however they are reported) must be handled in some fashion. You cannot simply ignore them except in rare cases, you must always make some kind of provision for failures. Sometimes the appropriate response to failure (some kinds, anyhow) is to "fail fast and hard" as another poster recommends. Sometimes the response should be to pass the buck: "I'm reporting a failure because a lower level reported failure to me." Sometimes the response should be to cancel an operation in progress (e.g., don't commit the DB update), or to ask for outside help (e.g., show a dialog explaining that a user- provided URL doesn't respond). Sometimes it's a combination of these strategies (cancel the DB commit and then pass the buck). But coping with an error "rarely," if you just happened to be in a merry mood the day you wrote the code, is a recipe for failure. Errors *will* occur, even if they occur only once per million executions, and the code *must* do *something* in response. -- esosman@comcast-dot-net.invalid "Don't be afraid of work. Make work afraid of you." -- TLM