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 <mwil...@gmail.com> wrote:
> On Aug 21, 2:07 pm, Peter Becker <peter.becker...@gmail.com> 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 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
-~----------~----~----~----~------~----~------~--~---
