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: Tue, 9 Feb 2016 08:17:59 -0500 Organization: A noiseless patient Spider Lines: 42 Message-ID: References: <00ab9f4e-0f06-48ec-9a65-1a150c129a39@googlegroups.com> <8565ac8a-e4e2-4178-b4da-7f3a8ef8069d@googlegroups.com> <4deef389-ea5b-483a-bff5-4e1bdd45de2e@googlegroups.com> <2b736fcd-b72c-49b5-b4b8-9657ecebd51e@googlegroups.com> <6e3778e5-95d3-459e-9453-7ff7ebf38728@googlegroups.com> <37622de9-e99f-4a19-a8e0-8e9199fb91ea@googlegroups.com> <575f130e-2444-4eb8-bf11-91f13e1fb44b@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Tue, 9 Feb 2016 13:15:08 -0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="2d081e2f7155c28005d4472f67c2f43d"; logging-data="9789"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19tK65yZT8L0u4Wcmt1+jwX" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 In-Reply-To: <575f130e-2444-4eb8-bf11-91f13e1fb44b@googlegroups.com> Cancel-Lock: sha1:b1ahSyinN83GjyDSpDuoFzD3Z4w= Xref: csiph.com comp.lang.java.programmer:33715 On 2/9/2016 7:58 AM, boxzou@gmail.com wrote: > On Tuesday, 9 February 2016 02:22:14 UTC-5, Sebastian wrote: >> Am 09.02.2016 03:46, schrieb b...@gmail.com: >>> On Monday, 8 February 2016 17:23:45 UTC-5, Eric Sosman wrote: >>>> >>>> And he wrote >>>> >>>> "[...] javadoc can't list all the exceptions either [...]" >>>> >>>> which gets the same BIG DOWNVOTE from me, too. A programmer who won't >>>> document his code is doing no one any favors. >>>> >>> that's quite normal. You can only document a few exceptions. for example, JPA EntityManager.persist(object) can throw all kinds of exceptions, there is no way you can document all (db connection failure, constraint violation, object mismtach etc etc, I think EclipseLink have hundreds of exception codes, they didn't document them at the method or class level, but as a separate web page: https://wiki.eclipse.org/EclipseLink_Exception_Error_Reference_%28ELUG%29). There is another reason: you can plug in new database. JPA has no way to document the future new db exceptions. Nor should it. >>> >>> Another example is SSH library to execute commands on remote OS. can you document all the errors thrown back by all the linux/unix commands? >>> >> Isn't that where wrapping for once is useful? Like >> InvocationTargetException? > > wrapping obscures the exception. Do you know how to handle an InvocationTargetException other than log it? Logging is not handling. Logging is a useful adjunct to handling, in that it exposes some information for post-event analysis: debugging, health monitoring, and all the rest. Your boss says "Perform this task," but you're unable. Logging is writing "I can't" on a sticky note your boss doesn't see. He will be unhappy if that's all you do, because you didn't "handle" his task: You "dropped" it. Question: What does the catch block do beyond emitting a log entry? Throw a new exception? Re-throw the original? Close a few streams? Mark a cache entry as "stale?" Abandon the current operation and move on to the next? Some combination of these and other actions? *That's* handling. -- esosman@comcast-dot-net.invalid "Don't be afraid of work. Make work afraid of you." -- TLM