X-Received: by 10.66.233.137 with SMTP id tw9mr9709340pac.47.1454628677070; Thu, 04 Feb 2016 15:31:17 -0800 (PST)
X-Received: by 10.182.74.233 with SMTP id x9mr231555obv.19.1454628677035; Thu, 04 Feb 2016 15:31:17 -0800 (PST)
Path: csiph.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!news.glorb.com!hb3no732548igb.0!news-out.google.com!l1ni3112igd.0!nntp.google.com!hb3no732545igb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.java.programmer
Date: Thu, 4 Feb 2016 15:31:16 -0800 (PST)
In-Reply-To: <00ab9f4e-0f06-48ec-9a65-1a150c129a39@googlegroups.com>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=216.58.18.221; posting-account=yY21dwoAAAAwR_FNQzoIu2mx_B6Ohn1d
NNTP-Posting-Host: 216.58.18.221
References: <00ab9f4e-0f06-48ec-9a65-1a150c129a39@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <8565ac8a-e4e2-4178-b4da-7f3a8ef8069d@googlegroups.com>
Subject: Re: Java Checked Exception is BAD!
From: boxzou@gmail.com
Injection-Date: Thu, 04 Feb 2016 23:31:17 +0000
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Xref: csiph.com comp.lang.java.programmer:33606

On Thursday, 4 February 2016 10:19:27 UTC-5, box...@gmail.com  wrote:
> http://tri-katch.blogspot.com/2016/02/java-checked-exception-is-bad.html
>=20
> In the above link I proved in theory why checked exception is BAD.
>=20
> It's sad to see that even though checked exceptions have been proven a mi=
stake in practice and abandoned by major software packages like Spring Fram=
ework/Guice/EclipseLink/Hibernate etc, the following is still listed as a g=
uideline on the official java tutorial:
>=20
> https://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D begin quote =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Here's the bottom line guideline: If a client can reasonably be expected =
to recover from an exception, make it a checked exception. If a client cann=
ot do anything to recover from the exception, make it an unchecked exceptio=
n.
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D end quote =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> This is totally misinformation!  Checked exception is a mistake.  It shou=
ld be rid of from Java (luckily no other language has this concept).

Maybe I was not clear in the blog. I think all problems with Checked Except=
ion arise from the following contradiction:

1. Exception should be handled rarely, vs
2. Exception must be handled (either catch or throws).

Do not think throws is so simple. It creates a lot of problems as witnessed=
 by Bruce Eckel, Rod Waldhoff and Alan Griffiths and many others.