[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: C++ exceptions
From:       Jeffrey Brendecke <yakhki () yahoo ! de>
Date:       2005-12-06 12:09:42
Message-ID: 200512061309.42715.yakhki () yahoo ! de
[Download RAW message or body]

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 <<
[prev in list] [next in list] [prev in thread] [next in thread]