In article <✉forums.inprise.com>
	Raoul De Kezel <✉hotmail.com> wrote:

> > If the programmer is worth their salt and aware of exception safety,
> > they should be able to do it without much difficulty.
> 
> Barry, please dont take it bad, but I think this is a pretty naive
> sentence. 

It's pretty easy. Expect exceptions everywhere. Any time you do
anything, think what will happen if an exception occurs right now; most
of the time, nothing much bad will happen.


It's when you have states/modes (like databases; your insert/edit/post
etc.) that it gets tricky. Thankfully, I don't do much database
programming; Delphi's database architecture almost makes me weep in
despair, any time I have to deal with it.


Essentially, all you have to do is write in a transactional style, where
every action is either committed or rolled-back based on what exceptions
get thrown up by lower layers.


If stuff gets committed, then the typical transaction looks like:


try
  // stuff
finally
  // commit
end;


If stuff gets rolled-back if an error occurs, it looks like:


try
  // stuff
except
  // roll back
  raise;
end;


However, the roll-back mechanism isn't needed often because most of the
time the architecture is designed in such a way as to make it implicit:


try
  // stuff
  // commit here
finally
  // free stuff; implicitly rolls back if commit was never reached
end;

> > Specification of anticipated exceptions is a misguided dead-end.
> 
> That's a very bold statement :-)  

It's a personal opinion, and I feel it very strongly. It goes against my
religion of "expect exceptions everywhere", because it implies that you
only have to expect some exceptions somewhere; to my way of thinking,
that's completely misguided.


-- 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