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 Exceptions Date: Mon, 8 Feb 2016 13:30:14 +0100 Lines: 45 Message-ID: References: <56b601cc$0$23722$e4fe514c@news.xs4all.nl> <25c9bda0-2d07-4339-a7cd-2b868584117d@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net I/qE6KbDC0Fr8q5tzea6dQhf7PRhTtp+ZhtD/TV0c0cCvjEM8= Cancel-Lock: sha1:TVDApJ5/tatc4rzTVI+HUlKy5a4= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 In-Reply-To: <25c9bda0-2d07-4339-a7cd-2b868584117d@googlegroups.com> Xref: csiph.com comp.lang.java.programmer:33669 On 07.02.2016 23:39, boxzou@gmail.com wrote: > On Sunday, 7 February 2016 15:56:15 UTC-5, Robert Klemme wrote: >> On 07.02.2016 15:09, Stefan Ram wrote: >> >>> Some methods can't know all their exceptions at >>> documentation time because they call other methods that >>> are only determined at runtime. But this is also the case >>> where checked exceptions are difficult to use. >> >> How should that be possible? Can you show an example where not all >> checked exceptions can be determined at documentation time (i.e. after >> successful compiling)? > under JPA, you can plug in Oracle DB, Derby DB, IBM DB2. Each db > throws different kinds of exception although they are all subclasses > of SQLException. Theoretically you can also plug in Google big table > which does not throw SQLException at all, or some other things. > There is no way JPA API can document all these exceptions! Well, the API documents SQLException so from a caller's perspective he knows what to catch - and there won't be any exception thrown that could escape that catch. If anything I'd rather argue that the design of JDBC has the flaw to not distinguish basic classes of errors that can surface and declare them as checked exceptions, for example: - syntax errors in SQL executed (this could even be considered a runtime exception because it is a coding error of some sort) - communication issues with a remote database server - constraint violations - resource issues, e.g. database server cancels an SQL statement because it uses too many resources (time, memory, IO) And you use JPA to abstract the concrete database model used so it would be very unwise to start writing catch clauses for all sorts of database specific exceptions (apart from the fact that this is often not possible because you add JDBC drivers at deployment time so the compiler does not see them). So it is practically not possible (even with unchecked exceptions!) and it is not wise from a modularity point of view. And it is not needed since you usually get all the details of nested exceptions in an application's log. robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/