Reinier Zwitserloot wrote:
> Concrete examples:
>
> Runnable does not let you throw Exceptions. Anyone up for defending
> this grievous API design? The amount of annoyance that this is caused
> me is almost limitless.
>
Where would that exception go?
> Servlets require you to wrap checked exceptions into a
> 'ServletException', which is almost as bad. *ANY* exception caused by
> a servlet is cause to log it and return 500. Why the heck do I need to
> wrap these things? Who is helped by that? Which code has become more
> readable because of that?
>
It makes some sense to me. The servlet container cares only about the
fact that the servlet failed, the question why is rather secondary on
that level. You could also imagine that subtypes are used to distinguish
the actual problem.
If you just allow any exception to go through (e.g. by letting the
methods throw Exception on the API level), programmers will forget to
handle things they could handle.
> InputStream.close() throws IOException. Nuff said.
>
That only proves that exceptions are used badly in the JDK.
> NumberFormatException is a likely scenario that the calling code can
> usually handle directly, yet its a runtime exception. Making the case
> that IOException ought to be a runtime exception is a lot harder to
> make, so this is quite inconsistent.
>
I totally agree, not catching NumberFormatException is something I
consider a code stink -- unless the parsed string is a constant it is
probably wrong. If it is a constant it begs the question: "Why?".
> new String(whatever, "UTF-8"); throws an UnsupportedEncodingException.
> The JVM Spec says that you aren't a JVM unless you support at least
> the basic set of charsets. UTF-8 is there. So is ISO-8859-1, and so is
> US-ASCII. Thus, that line ought to be throwing a VirtualMachineError
> if UTF-8 is not found.
>
IMO there should be accessor methods for the common encodings. Again:
bad API design in the JDK, which we all seem to agree upon.
> FilterInputStream and FilterOutputStream's methods throw IOException,
> but if I feed it a ByteArrayInputStream, or I let it filter into a
> ByteArrayOutputStream, then an IOException can never happen.
>
Which could be solved by having safe and unsafe versions of the interface.
> Any attempt to use a "closure" (anonymous inner class literal) where
> the "closure" is handed off for immediate processing, right there on
> the spot, nevertheless does not inherit the checked exceptions that
> can legally be thrown on the declaration site. There are a number of
> interfaces which are clearly supposed to be used this way, but its
> impossible to get the API right for these things. This is why the BGGA
> proposal has a very awkward part in it do deal with this issue.
> Designing such interfaces with a 'throws Throwable' clause doesn't
> help; you need to repeat the clause (1) and it would mean that calling
> code has to now deal with all throwables. It's just a disaster. Here,
> imagine you want to sort-in-place a list of files depending on their
> canonical path:
>
> Collections.sort(listOfFileObjects, new Comparator<File>() { public
> int compare(File a, File b) { return a.getCanonicalPath().compareTo
> (b.getCanonicalPath()); }});
>
> Except the above code won't fly; getCanonicalPath throws IOException.
> Even if I wrap this entire line in a try/catch block, that won't help.
>
> How's that for examples?
>
A nice list of examples where checked exceptions don't work well in the
JDK. The latter points to an issue between checked exceptions and
closures in the Java context. Does that in any way imply that the idea
of checked exceptions is bad in general or that it is impossible to use
checked exceptions in a positive way in Java? I don't see that yet.
Peter
>
> On Aug 18, 5:55 pm, Alexey <inline_f...@yahoo.com> wrote:
>
>> On Aug 18, 11:03 am, Casper Bang <casper.b...@gmail.com> wrote:
>>
>>
>>> On 18 Aug., 16:51, Alexey Zinger <inline_f...@yahoo.com> wrote:
>>>
>>>> Maybe what this discussion needs is some real-world anecdotes of checked
>>>> vs unchecked exceptions in production environments and how they helped or
>>>> not to save the day.
>>>>
>>> I would think it's a fairly real-world anecdote how no other language
>>> following Java introduced checked exceptions. Also you will have a
>>> much easier job coming up with language guro's against them than for
>>> them I think.
>>>
>> I'm not convinced of that. So far, most of the complaints come from
>> people talking about the imposition checked exceptions create on the
>> coder. There's grumbling of misuse and hiding of exceptions by
>> improper logging or catching and ignoring, but not much in the way of
>> real-world scenarios. Not saying those statements aren't grounded in
>> reality, but let's throw out some concrete situations to dissect and
>> see how they could have been helped.
>>
>> I'm not a fan of how checked exceptions are used in specific API, JSE
>> included, but I'm not against the concept as a whole. Lately, I've
>> been working almost exclusively on web projects, many of them using
>> GWT. Some of those projects were started by my predecessor and, not
>> to put the guy down, but there's some horrendous exception handling
>> there. Lots of catch(Exception), inconsistent and often broken
>> logging, and all sorts of nasties like that. Some of the scenarios
>> that were very difficult to debug (and still are in some parts of the
>> systems) are the ones, where there's use of a 3rd party Excel
>> authoring library (jxl as I recall). Occasionally, the code comes
>> across a situation that breaks certain assumptions (unexpected
>> formatting, or the like) and those almost inevitably get buried in
>> ignored exception catches. I never get proper time to go through it
>> (not that I'm that excited to do it) and clean it up, and so time and
>> again we bump into some new extravagant way the system breaks.
>>
>> Now, one would read this and say, "Aha! -- if only there were no
>> checked exceptions, your predecessor would have written his sloppy
>> code in a way that would allow those to propagate to the top layer
>> (servlet container) and you would have seen it in some log and
>> probably on some screen." Indeed, some of those exceptions are of
>> checked variety. However, the code was written in a manner that
>> didn't stand a chance. He simply assumed there would be no erroneous
>> situation and dealt wrote EVERYTHING (file IO, DB, parsing/formatting,
>> etc.) under a single try block and figured he'd just log whatever was
>> caught in one catch (reuse, right?). And in fact, there ARE plenty of
>> ways to handle these situations based on whatever kind of exception
>> might arise. For instance, multiple formats might be tried on a
>> single value before giving up, whereas a general Excel file read
>> exception is probably unrecoverable.
>>
>> And then there's the unintended catching of RuntimeException that's
>> sprinkled around there that also just lumps lots of different
>> situations into one try/catch. This one can't be fixed by killing off
>> checked exceptions, obviously.
>>
>> Overall, much of the problems could have been avoided by a better
>> internal API design, that would separate different layers of
>> functionality into finer granularity and would make it clear to the
>> developer how to handle each and every exceptional situation
>> differently, while still cleaning up resources when possible. So I
>> don't think simply eliminating checked exceptions would have been the
>> answer. I think both checked and unchecked have their place.
>> Remember, that just because Java is the only language with checked
>> exceptions, doesn't mean that it's a dead end. I do think that real
>> world implementations have scared some people off the idea.
>>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
