X-Received: by 10.182.87.2 with SMTP id t2mr8522992obz.20.1454613057297; Thu, 04 Feb 2016 11:10:57 -0800 (PST)
X-Received: by 10.182.231.229 with SMTP id tj5mr206385obc.13.1454613057275; Thu, 04 Feb 2016 11:10:57 -0800 (PST)
Path: csiph.com!feeder.erje.net!2.us.feeder.erje.net!news.glorb.com!peer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!o2no2198512iga.0!news-out.google.com!kr2ni6618igb.0!nntp.google.com!hb3no639536igb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.java.programmer
Date: Thu, 4 Feb 2016 11:10:57 -0800 (PST)
In-Reply-To: <3e5ccef4-d91a-4d66-be03-c8f0b58df128@googlegroups.com>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=137.254.4.13; posting-account=yY21dwoAAAAwR_FNQzoIu2mx_B6Ohn1d
NNTP-Posting-Host: 137.254.4.13
References: <00ab9f4e-0f06-48ec-9a65-1a150c129a39@googlegroups.com> <3e5ccef4-d91a-4d66-be03-c8f0b58df128@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <94cd2881-e72e-45f6-a0ba-e4816a073bdc@googlegroups.com>
Subject: Re: Java Checked Exception is BAD!
From: boxzou@gmail.com
Injection-Date: Thu, 04 Feb 2016 19:10:57 +0000
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 2779
X-Received-Body-CRC: 3522060153
Xref: csiph.com comp.lang.java.programmer:33586

I am a java programmer for 15 years (since 2001).  How about you?

On Thursday, 4 February 2016 11:15:58 UTC-5, Eric Douglas  wrote:
> Checked exception is the norm.  How long have you been programming Java?
> I can't imagine how anyone could "abandon checked exceptions" but I'm not=
 familiar with the frameworks you mention.
>=20
> Normally an application has a try catch block for all possible checked ex=
cpetions, and sometimes it handles them differently while sometimes it does=
n't care.
>=20
> If you're passing a file name into a method you need to know which except=
ion it's getting.  If it's a FileNotFound you might ask the user for a new =
file name.  If it's a security exception you can tell the user they don't h=
ave rights to update that file.  If it's an IOException maybe there was a n=
etwork connection bug, maybe you want to just try again, or tell the user t=
here was a problem and give them some options.
>=20
> For an example that doesn't care, my application API calls the pdfbox API=
 to read an existing PDF file and render it to the screen.  I catch every p=
ossible exception and just set a boolean return value for my method which j=
ust says it worked or not.  While the pdfbox API throws a RunTimeException =
(which is not normally caught and crashes the application if you don't catc=
h it) if there was a problem reading the PDF because of the security provid=
er, I don't want that to crash.  For all errors/exceptions reading/renderin=
g the PDF I just send the PDF to the user to attempt to open with Adobe.