After initially disagreeing completely I can see a point in that
exceptions break the normal control flow and can thus cause surprising
behavior. But I agree with you that the alternatives aren't necessarily
better.
Somehow error handling is never easy. Just take one of these nice
graphical displays of code execution (UML, workflows) and add the error
handling in. Particularly in workflows your nice and simple graph
suddenly turns into a mess. The same is true on the code level: code
that is pretty straightforward for the normal case can quickly turn into
a mess once error handling is added, no matter what system of error
handling you use.
One note: I think you could probably write a system where most common
technical errors are handled via return values, but you would need to
have a lot of unions/eithers. That approach is quite comparable to the
checked exceptions (I have done this comparison the other way around
before), but the control flow is quite different. The File class in Java
stands out so much since it is different, but it might just work
somewhere else.
Peter
Reinier Zwitserloot wrote:
> I can't let this horse puckey about 'exceptions are less readable'
> stand. It's hogwash.
>
> Consider that any operation, anywhere in the entirety of your java
> source base, can throw just about any exception. Not just
> theoretically, but practically: You can get an OutOfMemoryError, or a
> ClassNotFoundError, for example. Actually trying to shove these status
> conditions into some sort of return object that tracks exactly what
> went right and what went wrong is *PHENOMENALLY* more boilerplate than
> even java's verbose checked exception system. I take it as axiomatic
> that returning an integer that holds an error code is utterly insane.
>
> At best you can make an argument that you ought to keep exceptions for
> the very exceptional, and to push the line between 'exceptional' and
> 'alternative exit condition' as far to the exceptional side as you
> can; e.g all file operations ought to return a FileOperationResult
> object.
>
> But, I put it to you: How happy would you really be with such an API?
> Because it exists, folks. java.io.File. Instead of throwing
> exceptions, it returns booleans. And it's so hated, its getting
> replaced in java 7. It's been tried, it's failed miserably. You'd have
> to return an object that states the exact problem that actually
> occurred, and, at that point, aren't you just writing the equivalent
> of:
>
> public IOException mkdir() {}?
>
> whether the IOException is returned normally (or, more likely, in the
> case of a method that also needs to return some actual data, as an
> Either and you'd have to query the Either to figure out what happened
> - d'oh) or 'returned' via the exception mechanism is relatively
> speaking a very small point. A much bigger point is that you just
> can't get around the notion that you NEED some sort of exception
> system to handle the truly exceptional - unless we'd all prefer going
> back to the 'core dumped' days, and that there's a real need to have
> semi-exceptional conditions that you'd like, by default, to walk up
> the stack quite a bit before being handled.
>
> Here, simple example: You write a servlet, and something untoward
> happens - say, a database issue (SQLException). In plenty of
> situations you don't want your servlet to handle it - you want that
> problem to walk up the stack, back to the servlet container that knows
> to return a 500, log something, and maybe try to notify an
> administrator. It would be hopeless if you had to rely on the serlvet
> to pass through problems. It would also make changing APIs to add new
> flavours of the exceptional much more problematic, and as
> theoretically sound it seems to say: But public APIs shouldn't ever
> change! - that's not very practical. The exceptional stuff is the
> first thing APIs are likely to change, exactly because it is so
> closely related to implementation details.
>
>
> Joel was dead wrong.
>
>
> On Aug 21, 3:40 pm, Martin Wildam <[email protected]> wrote:
>
>> On Aug 21, 2:07 pm, Peter Becker <[email protected]> wrote:
>>
>>
>>> I take the point that it is possible to make code harder to read using
>>> exceptions in a way that is not possible without. I must admit I didn't
>>> really think it through when I read Joel's blog post.
>>>
>> I think the reduced readability is the core disadvantage of using
>> Exceptions.
>> And I think that it is easier to create buggy code with exceptions -
>> especially for beginners.
>> (I know that most of those doing Java do it since a long while but
>> they get older and junger people must somehow follow them).
>>
>>
>>> There is the opposite danger, though: ignoring a return value. Since
>>> C-like languages allow functions to be called as statements, it is
>>> pretty easy to just ignore the fact that there is an error code
>>> returned. Checked exceptions force you to deal with the issue.
>>>
>> Whether it is an exception or a return code you always can drop it or
>> deal with it. When I use a method like openFile or something the first
>> thing automatically is to look for a return code.
>>
>>
>>> Of course that problem could also be fixed by disallowing calling
>>> functions as statements, which I think would be a good idea not just for
>>> this reason.
>>>
>> I would loose then the option to ignore the result which may make
>> sense (e.g. loading an optional configuration file).
>> People want closures, annotations and all the like but then I should
>> get limited how to use a simple method?
>>
>> Best regards, Martin.
>>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
