In article <3b7f9bcc$1_1@dnews>
	"Kristofer Skaug" <✉skaug.demon.nl> wrote:

> atomicised operations focused on handling errors close to the source
> of error (for specific handling) can do with a lower degree of
> nesting. i.e.

Why do you need to handle the errors? If you really need to handle the
errors, then (IMO) the operations should be in completely separate
functions, so that you can eliminate the drudgery of handling the same
errors over and over again.

> try 
> [...]
> try
>   opN
> finally
>   cleanup / error handle opN
> end;
> 
> we discussed this approach before.

Still; if you were using return values for errors, your code would look
like:


  if not opN then
  begin
    // handle opN failing
  end;
  // clean up after opN


Not a whole lot different.


Another thing: your operations above are sequential; because you handle
errors after each step, it seems to be implied that each step doesn't
depend on the previous step completing (otherwise the small failure
would prevent the completion of the larger transaction).


But then again, if you really really need to continue, to struggle
through no matter how much coding around issues you need to do, then
whether or not exceptions are present isn't going to make much
difference; the code occupied with the struggle will dwarf any
difference between error codes and exceptions.


If you feel it's cluttered, have you considered making your operations
nested functions, like:


---8<---
procedure BigOp;


  procedure Op1;


    procedure TryOp1;
    begin
    end;


    function TryHarderOp1: Boolean;
    begin
    end;


  begin
    try
      TryOp1;
    except
      if not TryHarderOp1 then
        raise;
    end;
  end;


  // ...


begin
  Op1;
  Op2;
  // ...
  OpN;
end;
--->8---


Just an idea; it works for me.


-- Barry


-- 
  If you're not part of the solution, you're part of the precipitate.
Team JEDI: http://www.delphi-jedi.org
NNQ - Quoting Style in Newsgroup Postings
  http://web.infoave.net/~dcalhoun/nnq/nquote.html