On Aug 21, 11:33 am, Peter Becker <peter.becker...@gmail.com> wrote:
> Number one clearly does not apply to checked exceptions, number two
> applies to returning values, too. Of course you could assign a value and
> follow the approach of having a single return statement at the end, but
> I never understood why the resulting code should be any easier.
Both, "They are invisible in the source code." and "They create too
many possible exit points" target the "hidden" jumps in code. While
debugging Java code with heavy use of exceptions I found out plenty of
possibilities in code where some code lines were or were not executed
depending on the exceptions occurring. In reality I would need to
write plenty of nested finally blocks to ensure correct handling of
all steps.
Let me draw a constructed extreme opposite example not using
exceptions (before you comment on this example, know that I already
understood that this is no good practice):
boolean goAhead = true;
if (!checkEdits()) goAhead = false;
if (!checkConfig()) goAhead = false;
if (!openDestinationFile()) goAhead = false;
//Prechecks failed so we leave
if (!goAhead) return goAhead;
//Start with regular work
if (goAhead)
{
//We do some first transaction
startTransaction();
doSomeSaveWorkThatCannotFail();
if (!doSomeTransactionWork()) goAhead = false;
}
if (goAhead)
{
doSomeMoreSaveWorkThatCannotFail();
yetAnotherBunchOfOperations();
if (!saveSomeDataOrDoSomethingElse()) goAhead = false;
}
if (goAhead)
commitTransaction();
else
rollBackTransaction();
The difference here is that you have no ACCIDENTALLY LINE SKIPPING.
If you use instead something like this:
try
{
checkEdits();
checkConfig();
openDestinationFile();
}
catch (Exception e)
{
throw new PreCheckException();
}
try
{
startTransaction();
doSomeSaveWorkThatCannotFail();
doSomeTransactionWork();
doSomeMoreSaveWorkThatCannotFail();
yetAnotherBunchOfOperations();
saveSomeDataOrDoSomethingElse();
commitTransaction();
}
catch (SomeBusinessLogicException e)
{
//Where did I get my Exception from? Until which line the above
has been processed?
rollBackTransaction();
}
catch (SomeTransactionException e)
{
//Where did I get my Exception from? Until which line the above
has been processed?
rollBackTransaction();
}
catch (IOException e)
{
//Again we need the rollback
rollBackTransaction();
}
For the first part it makes no big difference - a little less work
with using exceptions.
In the second part you can't easily see (without examing javadoc of
the called methods) which lines could have produced the exception.
Encapsulating every single operation with try-catch is clearly not an
option as it produces much more boilerplate (if several lines could
throw the same exceptions) than using return codes. An advantage of
using return codes is having a clear information about the overall
status of the whole operation "automatically".
BUT: I think the handling of the different exceptions can be solved
with throwing your own Exception type instead of returning a
resultCode. And I think to remember something like this recommended by
Josh Bloch in his book "Effective Java" (just don't remember which
item and I don't have the book at hand). The only thing is the need of
an extra Class for your application exception(s). Hey, and you can
throw an exception that contains either a return code - there you
would have everything. - Remaining issue is only that in some cases I
simply don't care of the return codes and I can decide this in the
parent method. But this can be solved using Unchecked Exceptions
instead of checked exceptions. - And this is the point where I love to
have the option of using checked or unchecked exceptions.
Thank you guys - with your help I got cleared that up.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
