On Tuesday 06 December 2005 09:31, R.F. Pels wrote:
> 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.


I agree with the point made here:

> [...] 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.

This illustrates the problem with reporting issues that interrupt the flow of
logic through checking return codes. The programmer cannot focus on the work
flow but must instead continually, pro-actively, and diligently test for
error conditions. From my experience, doing this is such a pain that error
checking is often omitted or not thoroughly implemented, resulting in the
worst case: Errors getting swallowed. The use of exceptions frees the
developer from having to keep doing this sort of checking. If unexpected
exceptions crop up and cause a problem it is easy locate the problem and
implement a fix as part of testing. Exceptions are also useful because if
they are properly designed, they can bundle the error message, making
reporting simple.

If the underlying issue against adopting exceptions is that they can cause
problems if used improperly (e.g., in destructors), then the solution is to
research and implement guidelines for the proper use of exceptions (and error
handling in general) in C++/KDE so that everyone can know what to do and how
to do it.

From my experience elsewhere and and in this relatively short time monitoring
this mailing list, a lengthy and often passionate discussion arises any time
someone discusses using exceptions.

I would be glad to lead an effort to compile a document on error handling and
proper use of exceptions as a means of getting involved with KDE and would be
interested in working with anyone on running such a document through any
applicable review/approval process. This does not mean all error handling
must be implemented through exception handling, but rather to better inform
users on the pros and cons of the different recommended approaches, so
developers can make informed decisions based on recommendations approved by
KDE. With something like this, I think much progress can be made in
standardizing error handling in KDE, which from what I have read has been a
problem. It could also head off long discussion threads on the topic as one
can just point to a document on the website.

--

Jeffrey Brendecke

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