incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicholas Sterling <Nicholas.Sterl...@Sun.COM>
Subject Re: Design guidelines
Date Wed, 04 Mar 2009 06:43:17 GMT
With regard to null pointers vs. exceptions...

If you subscribe to the philosophy that simple things should be simple, 
then throwing unchecked exceptions seems like the way to go.  If I'm a 
sustaining engineer who just wants to write a quick throw-away program 
to rummage around through a heap dump looking for something, then I just 
want to code for the case where the heap is valid and get an exception 
if it isn't.  I don't want to have to check the results of method calls 
and do something appropriate if there's a problem.  Nor do I want the 
program to proceed on if there is corruption, generating confusing 
results or dying down the road with some bizarre exception.  I want to 
assume all is well, and get an immediate exception if that assumption is 
violated.

Even if I'm trying to handle the possibility that the heap is corrupted, 
I still probably want to do it in layers.  I'll let an exception handler 
around the whole shebang handle most problems; for a few I'll be 
cleverer, catching that specific exception and recovering in some 
special way.  But I don't want to have to write code to handle every 
possible thing that could go wrong.

Of course I think that null pointers are fine if I ask for something 
which may or may not exist in a valid heap.  But if I'm asking for 
something that's supposed to be there, I don't want a null pointer back 
if it's not -- I want an exception.

Nicholas


Mime
View raw message