Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / February 2006

Tip: Looking for answers? Try searching our database.

Which exception idiom do you prefer?

Thread view: 
stevengarcia@yahoo.com - 28 Feb 2006 00:03 GMT
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
the following (silly) example:

Which exception block below do you prefer coding and/or reading?  This
is in reference to a class that will generate commonly found and
consistent exceptions in our application.  Please give your reasons:

public void sendCommand() {
 String command = null;
 if (condA) {
   command = getDriverCommand();
 }
 else if (condB) {
   command = getUniqueCommand();
 }
 else {
   ExceptionUtils.throwSpecificException(...);
 }

 sendCommandInternal(command);
}

OR

public void sendCommand() {
 String command;
 if (condA) {
   command = getDriverCommand();
 }
 else if (condB) {
   command = getUniqueCommand();
 }
 else {
   ExceptionUtils.throwSpecificException(...);
   return;
 }

 sendCommandInternal(command);
}

The differences are subtle.  In the first block, I initialize the
String command field to be null.  If condA or conB are not met, I need
to throw an exception, and I have a helper class that will throw an
exception inside throwSpecificException(...).

In the second block, I do NOT initialize the String command field,
because I know that in the subsequent lines it must be set.  If condA
and condB are not met, I am going to throw an exception.  But I must
add the "return" statement directly after the ExceptionUtils line
because the class will not compile if I don't:  Java complains that on
the line sendCommandInternal(command) that "the variable command may
not be initialized."

Which way do you prefer coding this?  Or is there a completely
different way that I'm missing.  I like the second way because by not
setting command to null, I know that later in the method it MUST be
set.  But I don't like adding the return line after the ExceptionUtils
line.
Adam Warner - 28 Feb 2006 00:47 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
> 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
John C. Bollinger - 28 Feb 2006 02:13 GMT
> 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.


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.