Re: Exception Names
On Mar 28, 9:36 am, Tom Anderson <t...@urchin.earth.li> wrote:
On Fri, 27 Mar 2009, Bent C Dalager wrote:
On 2009-03-27, Tom Anderson <t...@urchin.earth.li> wrote:
Personally, i'd also like to see Map.get throw a KeyNotFoundException
or some such instead of returning null when a key isn't in the map, bu=
t
i think most people wouldn't agree with me on that.
This seems very situational. In some use cases, a Map receiving lookups
of entries it doesn't have is considered entirely normal (a cache
perhaps) and so shouldn't be handled as an exception (and having to
first do a boolean lookup of the type "isEntryPresent" only then to cal=
l
get() on the same entry seems wasteful) and a null return value is both
useful and proper. In other uses you only look up values you know shoul=
d
be there and in these cases a miss should be handled as an exceptional
condition.
I certainly agree that both these use cases are valid (although i'd bet
the latter is ten times more common), but i don't see why having a null
return is necessary to address the former. This code:
Thing value = map.get(key);
if (value != null) {
dealWithValue(value);}
else {
dealWithLackOfValue();
}
Is trivially rewritten as:
try {
Thing value = map.get(key);
dealWithValue(value);}
catch (KeyException e) {
dealWithLackOfValue();
}
With no loss of readability. There is a potential performance penalty, bu=
t
i don't believe it would be significant with modern VMs.
Many people will dislike the latter version because it 'abuses'
exceptions. I think this betrays an overly dogmatic attitude to
exceptions, but it's a matter of taste.
Returning -1 or null to indicate the absence of a value is not 20th
century C bullshit. It is an exceedingly common pattern that is easily
understood.
The notion that an exception is a bad thing in Java is a useful norm.
It means that unhandled checked exceptions are identified as potential
problems. It means that exception handling blocks are understood to be
blocks of code outside the normal flow of the program. When I look in
a catch block, I expect to see error logging, or exception wrapping in
an exception class that has additional information about the error.
How does your notion extend to String.indexOf(char)?
public class Emailer {
public void sendEmailEx(String address, String message) {
// No C bullshit.
try {
address.indexOf("@");
sendToRemoteMachine(address, message);
}
catch (CharacterNotFoundException e) {
putInLocalHostMailbox(address, message);
}
}
public void sendEmailReturn(String address, String message) {
// With C bullshit.
if (address.indexOf("@", -1) == -1)
putInLocalHostMailbox(address, message);
else
sendToRemoteMachine(address, message);
}
}
In the case of indexOf, what "default" value would I ever return
besides an error indicator? Why are we calling it a "default" value
when it is really just the reintroduction of the function you're
trying to replace?
The thing that most motivates me to want the latter version is that it
makes it impossible to ignore absent keys. With a null return, code like
this:
The ability to ignore the absence of a value is one of the benefits of
returning a -1 or null result. Are you suggesting that
CharacterNotFoundException should be a checked exception? Does this
code motivate?
if (address.matches("@")) {
int i;
try {
i = address.indexOf('@');
} catch (CharacterNotFoundException e) {
// Impossible to get this green in test coverage.
throw new RuntimeException("This will never happen.", e);
}
InternetMailer.send(address.substring(0, i), address.substring(i +
1), message);
} else {
putInLocalHostMailbox(address, message);
}
Basically, there are times when null or -1 is a valid response for a
function. It is not the same sort of coding horror as a COM error
result code. In the case of indexOf I can ignore the absence, or
ignore the index and test for absence, or I do both at the same time,
because indexOf really is a linear scan of the string for the first
occurrence of a character. It is a loop over the underlying character
array. I want the results of that algorithm. I know what to do with
that C bullshit.
Just like read is really a possibly blocking poll of an I/O device, or
a socket or stdin. It is not an iteration over a finite collection of
characters in memory.
Alan Gutierrez - alan@blogometer.com - http://blogometer.com