In article <✉forums.inprise.com> Raoul De Kezel <✉hotmail.com> wrote:
> > Also, an important point in this article > > is that free propagation of exceptions > > across the call stack is a threat to > > program stability unless you are able to > > recover states in your intermediate > > objects (or your objects are stateless). > > Soooo true, and one of the reasons to prefer error codes.
It isn't very difficult in Object Pascal with correct use of try..finally.
> In 1989, it was already well known how important it > is to automatically put the system back in a consistent > state when propagating exceptions. And more than a decade > later most mainstream langages dont support this (and > dont support well a formal specification of anticipated > exceptions, for that matter)
Specification of anticipated exceptions is a misguided dead-end.
> I used to program databases, which *do* automatically > restore system state when an exception is propagated. > When I see a database exception, I am 110% sure that > the system is in a consistent state. When I see a > Pascal exception, I pray...
If the programmer is worth their salt and aware of exception safety, they should be able to do it without much difficulty.
> > The same cannot be said of error codes > > since they do not automatically > > propagate. > > Sure. Error codes have a visibility that exceptions > dont have. That helps to prove correctness of propagation > or handling, and I certainly understand that people > working on critical software prefer error codes (in > languages without automated rollback)
Unfortunately, error codes can make code all but unreadable.
-- 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