On Tuesday 6 December 2005 08.49, David Johnson wrote:

> My point is that the nature of exception propagation means that it's an
> all or nothing affair. If a library uses it (such as kdelibs), then
> every application using that library must also use it or risk not
> catching a thrown exception.
> The same is not true for templates, multiple inheritance, STL,
> iostreams, RTTI, etc. While all of these are important, if they are not
> exposed in the API, then the application developer is not compelled to
> use them.
> The reason this is important is because C++ is a BIG language. It is
> unrealistic to expect a developer to use all parts of the language all
> the time.

Exceptions as a language construct are quite easy to understand and master.
Especially for the younger folks among us that have been exposed to Java,
where exceptions are part and parcel of the language as well as the classes
in the JRE. And - as a concept - it is not very hard to understand. Must
easier than templates or multiple inheritance.

> One thing I especially like about Qt is that you can be quickly productive
> without comprehensive expertise in all parts of the C++ language. A library
> which demands comprehensive knowledge (such as Boost) severly limits its
> audience.

But that is not because it uses exceptions. The reason for that is that Boost
is very technical in nature and uses almost all language features there are
in C++.

> My argument isn't that exception are bad, or even dangerous. Rather it's
> that exceptions should not be part of a general purpose library's API.

Which is where I vehemently disagree. Diligent use of exceptions makes it
possible to enhance the expressiveness of what you can do with the API
without having to resort to clumsy methods of error checking. Do you want an
example? Have a look at the QSqlDatabase and the QSqlQuery classes. Using
that requires you to call lastError every time you perform an operation on
one of them. That means that you are obliged to write at least two lines of
code for each time you want the services of those two classes.

Additionally, if the API specification is properly outfitted with throw
specifications, that enhances the insight a user will have in what the
contract will be when he is making an API call.

R.F. Pels, 3e Rompert 118, 5233 AL 's-Hertogenbosch, The Netherlands
+31736414590 ruurd@tiscali.nl http://home.tiscali.nl/~ruurd

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<