On Mon, 27 Feb 2006 16:03:22 -0800, stevengarcia wrote:
> In Java, if you don't initialize a variable then you can't use it in
> your code. This can sometimes lead to weird looking code. Consider
[quoted text clipped - 55 lines]
> set. But I don't like adding the return line after the ExceptionUtils
> line.
The return after the ExceptionUtils line is misleading. Furthermore if
your program logic is broken the method could return instead of informing
you that your program logic is broken. Build a "CannotHappen" runtime
exception class and throw that instead:
else {
ExceptionUtils.throwSpecificException(...);
throw new CannotHappen();
}
Your code that does not initialise command will now compile. The
CannotHappen code is self-documenting and protects you from
throwSpecificException accidentally returning. And one day you'll be
amused when you induce an exception that you really thought could never
happen.
Regards,
Adam
SMC - 28 Feb 2006 05:01 GMT
> On Mon, 27 Feb 2006 16:03:22 -0800, stevengarcia wrote:
>> In Java, if you don't initialize a variable then you can't use it in
[quoted text clipped - 72 lines]
> amused when you induce an exception that you really thought could never
> happen.
Another suggestion is to have ExceptionUtils actually return an exception
and throw it yourself. E.g.
else{
throw ExceptionUtils.getSpecificException(...);
}
That also captures the issue of ExceptionUtils doing something unexpected
(you'll either get a compile time or runtime error).
This way follows the common "factory" design pattern.
Sean
stevengarcia@yahoo.com - 28 Feb 2006 18:39 GMT
> Another suggestion is to have ExceptionUtils actually return an exception
> and throw it yourself. E.g.
[quoted text clipped - 5 lines]
> That also captures the issue of ExceptionUtils doing something unexpected
> (you'll either get a compile time or runtime error).
Yea, I do like this idea. Thanks.
> This way follows the common "factory" design pattern.
>
> Sean
> In Java, if you don't initialize a variable then you can't use it in
> your code. This can sometimes lead to weird looking code. Consider
[quoted text clipped - 36 lines]
> sendCommandInternal(command);
> }
I prefer this:
public void sendCommand() {
if (condA) {
sendCommandInternal(getDriverCommand());
}
else if (condB) {
sendCommandInternal(getUniqueCommand());
}
else {
ExceptionUtils.throwSpecificException(...);
}
}
Or possibly this:
public void sendCommand() {
String command;
if (condA) {
command = getDriverCommand();
}
else if (condB) {
command = getUniqueCommand();
}
else {
throw SpecificException();
}
sendCommandInternal(command);
}
It is poor form to initialize a local variable with a dummy value; the
compiler checks and resulting warnings about possible uninitialized
variables are there to /help/ you.

Signature
John Bollinger
jobollin@indiana.edu
stevengarcia@yahoo.com - 28 Feb 2006 04:38 GMT
> John C. Bollinger wrote:
> public void sendCommand() {
[quoted text clipped - 8 lines]
> }
> }
This is OK, there are times that something else must happen before
sendCommandInternal(). So the code gets refactored to add logging,
some other checking, etc. So it is just easier to put it outside the
if/else block.
> Or possibly this:
>
[quoted text clipped - 11 lines]
> sendCommandInternal(command);
> }
This is probably what most people do, but I might also prefer
throw ExceptionUtils.makeSpecificException(...);
This allows for consistent exception messaging and also gets around the
ugly return statement.
Very interesting.
stevengarcia@yahoo.com - 28 Feb 2006 05:02 GMT
> John C. Bollinger wrote:
> public void sendCommand() {
[quoted text clipped - 8 lines]
> }
> }
This is OK, there are times that something else must happen before
sendCommandInternal(). So the code gets refactored to add logging,
some other checking, etc. So it is just easier to put it outside the
if/else block.
> Or possibly this:
>
[quoted text clipped - 11 lines]
> sendCommandInternal(command);
> }
This is probably what most people do, but I might also prefer
throw ExceptionUtils.makeSpecificException(...);
This allows for consistent exception messaging and also gets around the
ugly return statement.
Very interesting.