I can follow your argument to some extent, but wouldn't the equivalent,
exception-based code have a try/catch block per if(goAhead)? I agree
that this would create code that is more verbose, but otherwise it seems
equivalent.
I take the point that it is possible to make code harder to read using
exceptions in a way that is not possible without. I must admit I didn't
really think it through when I read Joel's blog post.
There is the opposite danger, though: ignoring a return value. Since
C-like languages allow functions to be called as statements, it is
pretty easy to just ignore the fact that there is an error code
returned. Checked exceptions force you to deal with the issue.
Of course that problem could also be fixed by disallowing calling
functions as statements, which I think would be a good idea not just for
this reason.
Peter
Martin Wildam wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
