gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Nit


From: Momchil Velikov
Subject: Re: [Gnu-arch-users] Nit
Date: 22 Oct 2003 12:26:04 +0300
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

>>>>> "Tom" == Tom Lord <address@hidden> writes:

Tom> In other words, on the issues of safety and convenience, there is no
Tom> advantage of exceptions over error-codes: they require the same work
Tom> at every call-site and admit equivalent static and dynamic checking.

  No they don't.  In the exceptions case work is required only when an
exception is thrown, i.e. on the exception path, while with explicit
error checking work is required on the "main" path.

Tom> Robust code is doomed to be (often) verbose, tedious, and ugly, either
Tom> way: it has to check for every possible error, and it has to
Tom> explicitly handle the case of an unexpected error.  (If anything, the
Tom> error-code approach has some syntactic advantages here.)

  It is less verbose, tedious and ugly with exceptions, since they are
clearly (visually) separated from the "main" code and are proportional
to the number of types of exceptions as opposed to being proportional
to the number of call sites.

  Yet less verbose it becomes with RAII. (e.g. std::auto_ptr for a
simple example)

Tom> The final distinction between exceptions and error-codes is flow
Tom> control: exceptions make non-local exits while error-codes do not.
Tom> However, once we realize the need for a discipline of call-site error
Tom> filtering to use exceptions robustly, this issue disappears:
Tom> exceptions employed with a discipline of call-site error filtering
Tom> _do_not_perform_ non-local exits -- they can be replaced by a
Tom> `return'.  Once that discipline is employed, exceptions are, in
Tom> essense, reduced to error codes!

  At the source level you still can have non-local exits, i.e. when
the compiler generates catch-all+rethrow.  With the added benefit that
the compiler will take care simultaneously for _all_ exit paths,
including rethrow ones.

~velco




reply via email to

[Prev in Thread] Current Thread [Next in Thread]