Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: Java Checked Exception is BAD! Date: Sat, 6 Feb 2016 16:01:50 +0100 Lines: 51 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net KRrSWBptuWaEKVh8HO2xeQrr7ZxxqDQlTHEZGZE2guRwzWfHY= Cancel-Lock: sha1:fDloW+3INZBadqv08+kOVT9Phoc= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 In-Reply-To: <2b736fcd-b72c-49b5-b4b8-9657ecebd51e@googlegroups.com> Xref: csiph.com comp.lang.java.programmer:33628 On 06.02.2016 01:09, boxzou@gmail.com wrote: > On Friday, 5 February 2016 11:47:16 UTC-5, Eric Douglas wrote: >> On Friday, February 5, 2016 at 11:26:04 AM UTC-5, box...@gmail.com wrote: >>> by "rarely" I mean if you have a call stack where method3 calls method2 which calls method1: >>> >>> method1() >>> method2() >>> method3() >>> >>> when method1 throws an exception and method3 knows how to handle it, method2 should not be forced to handle. In real application the call stack can be very steep (many method calls) and for an exception only one frame/method knows how to handle the exception. The other frames/methods should not be forced to handle it. That's what I meant by "rarely". >>> >>> In application server case, usually most exceptions are just logged by the application server so that the application (and server) does not crash on an exception. There are very limited an app can do on most exceptions, like network outage, file accidentally removed, data accidentally removed from db, or due to bugs, these would usually require human intervention (fix network outage, put file back, fix data, fix bug etc). >> >> You still don't get it, and you still have yet to show a good example of how what you perceive to be a problem should be solved. >> How can any method "not be forced to handle" any exception? If method3 calls method2 which calls method1 and method1 encounters an exception do you think the norm should be to log the exception and continue as if nothing is wrong, or how do you propose method1 should tell method3 about the problem without telling method2? It could throw an unchecked exception, which method2 wouldn't have to do anything for and method3 could still catch, but the programmer writing method3 still needs to know about the possibility of this exception and code for it. It sounds like you're just making the huge assumption that causes many of the program errors in any language, that every programmer just knows every possible runtime error and writes handlers for them. > > As you said, if a runtime exception is thrown from method1 and method2 does not know how to handle it, method2 does not need to do anything and method3 can still catch that exception and handle it. The developer need know method2 might throw this exception. I am afraid we can not rely on checked exception to document this exception. Why? Suppose we have > > method3 calls method2a and method2b and method2c > method2a calls method1a1 and method1a2 and method1a3 > method2b calls method1b1 and mehtod1b2 and method1b3 > method2c calls method1c1 and mehtod1c2 and method1c3 > and each method1xy throws one exception say Exception1xy > now method3 signature would be > method3(...)throws Exception1a1, Exception1ab, Exception1a3, Exception1b1, Exception1b2, Exception1b3, Exception1c1, Exception1c2, Exception1c3 > > Do you think this will scale? That's why JDBC has SQLException and SpringFramework/JPA/Guice abandons checked exception altogether. I don't know why they did it. Can you provide any references to the reasoning of those projects to abandon checked exceptions? > This is only 3 levels, enterprise applications sometimes have 20+ levels. the throws clause would grow exponentially for each method. Soon the code would be nothing but exceptions! This is silly - for a number of reasons: - all intermediate methods can choose what exception to catch themselves and what they throw. - they can especially choose to throw another exception type wrapping the original one. - inheritance also works for exceptions Hiding exception conditions does not make all the ways go away in which various functionalities can fail. You need flexible and robust ways to handle them. That's what you get with exceptions. Cheers robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/