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
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:
If stuff gets rolled-back if an error occurs, it looks like:
// roll back
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:
// commit here
// free stuff; implicitly rolls back if commit was never reached
> > 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.
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