[3147] in java-interest
Re: I want to shoot myself!!!!!!!!!!!!!!!!!!
daemon@ATHENA.MIT.EDU (Thomas Ball)
Wed Nov 1 18:45:03 1995
Date: Wed, 1 Nov 1995 11:22:41 -0800
From: Thomas.Ball@Eng.Sun.COM (Thomas Ball)
To: jpayne@starwave.com
Cc: java-interest@java.Eng.Sun.COM
As a fellow idiot, I wasn't privy to the deep discussions of those who
came up with this policy. (by my speaking up, they'll rush to correct
me, however -- beating the bushes, so to speak ;-) As someone with
fifteen years of systems experience, however, here's the distinction
I'd make (and I'm probably wrong):
Basically, there are two groups of errors: those you can reasonably
recover from and those you can't. Opening a file is something an
application can frequently recover from, but handling a protection
fault normally isn't. Yes, in theory any error is recoverable, but the
cost of trapping that error may outweigh the benefits of recovery. A
RuntimeException (if I understand it correctly) is an error whose cost
of checking for it outweighs the benefit of catching it.
For example in Java, trying to catch errors with every possible memory
allocation is difficult (new objects get allocated all over the place),
so running out of memory is considered a RuntimeException. You can't
do much of anything at this point anyway, so just say bye-bye.
Checking for null pointers is also expensive -- to add checks each
place an object is dereferenced in Java would be an incredible
performance hit. In both cases, the costs outweigh the benefits.
Is this a pure, perfect implementation of exceptions? Of course not,
but it fits in perfectly with Java's pragmatic streak -- try to figure
out a practical balance between rigorous exception handling and runtime
performance which doesn't place *too* heavy a burden on developers.
The compiler tries to tell you which exceptions you should either catch
or promote, while ignoring those which are too costly. Kewl, as my son
says.
I've never created a RuntimeException, but looking through my code find
that I call System.exit() in a few places when my equivalent of an
assertion fails. Upon reflection, these exit calls should be replaced
with instances of a new AssertionFailure class, which will be a
subclass of RuntimeException. See the rule of thumb I'm using?
RuntimeExceptions should be reserved for those out-of-the-blue failures
no reasonable app or runtime can defend itself against -- everything
else should be a subclass of Exception.
Tom Ball
Java Products Group
P.S. You may want to get your medication adjusted, JP, as this subject
is hardly worth getting all riled up about. <grin>
> From daemon@java Wed Nov 1 10:22:23 1995
> To: java-interest@java.Eng.Sun.COM
> Subject: I want to shoot myself!!!!!!!!!!!!!!!!!!
> X-Info: To unsubscribe, send 'unsubscribe' to java-interest-request@java.sun.com
>
> Would somebody please explain to me when I should make an exception be
> a RuntimeException rather than just an Exception? Right now I want to
> make everything a RuntimeException because my life is hell.
>
> So please explain to me again (I realize everybody else on the planet
> already understands this) when something should be a RuntimeException
> rather than just an Exception (that needs declaring). You must have
> had something in mind when you came up with this distinction.
>
> Remember, you're talking to an idiot here, so make it simple and give
> lots of examples.
>
> Fondly,
> JP
> -
> This message was sent to the java-interest mailing list
> Info: send 'help' to java-interest-request@java.sun.com
>
-
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com
