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

List:       kde-devel
Subject:    Using exceptions in KDE4
From:       Jeffrey Brendecke <yakhki () yahoo ! de>
Date:       2005-12-20 17:02:21
Message-ID: 200512201802.22070.yakhki () yahoo ! de
[Download RAW message or body]

There have been some recent (lengthy) mail threads on the subject of using 
exceptions in KDE. There has also been some confusion as to whether there are 
technical reasons why exceptions should not used in KDE. Instead of adding to 
an already long thread, I am starting anew. I am summarizing the contributions 
made to the threads. If I misrepresented anything, please accept my apologies 
and let me know. Here, I will focus on the case for using exceptions 
throughout KDE, including the libs.

Even if it is decided that using exceptions throughout KDE4 is a bad 
thing and must be avoided at all costs, it is worth documenting that decision 
and posting the reasons for the decision for public reference. However, in 
that case it would advisable to describe the recommended error handling 
practices. If users should be avoiding exceptions, then there should be 
something that is better. I don't think checking return values and calling 
"getLastError" or similar falls into that category for reasons I give above. 
If there are good reasons for not using exceptions, then I think they should 
be good arguments for encouraging someone to develop for KDE as opposed to 
another platform.

If of interest, I am glad to compile the final information on using exceptions 
into a document that is reviewed and posted in some discoverable place on the 
KDE website. I just need to know what format it needs to be in, who would 
like to review it, and how I can best route the document for review.

I suggest that exceptions be made a part of the way code is written in KDE4, 
including the libraries.

Reasons Cited in Recent Mail for not Making More Widespread Use of 
Exceptions in KDE:
* Possible problems with Qt and exceptions.
* Not all developers want to use exceptions.
* Not all developers know how to deal with exceptions.
* Developers don't want to be faced with unhandled exceptions from libraries.
* There may be some performance reasons.
* Bloated binary size.
* Packagers may be unclear as to whether the Qt they are packaging has been 
built so as to support exceptions.
* Application compatibility between apps and the libraries (this would be an 
issue if, for example, the KDE 3 libaries were to suddenly throw exceptions).
* Some cases where misuse of exceptions has caused problems in debugging.
* Possible problems on MacOS X with exceptions.

Reasons for Using Exceptions Throughout KDE4:
* Exceptions are as much a part of C++ as any other part of the language and 
there is a good reason for them being there.
* Results in cleaner code focused on the program's logic. For an excellent 
discussion on this, I suggest the subsection entitled "Error-Checking 
Strategies" on pg. 112 of "Python in a Nutshell" by Alex Martelli published 
by O'Reilly (2003), where he compares the function-based model of "Look 
Before You Leap" with the exception-style model of "it's easier to ask 
forgiveness than permission."
* Negates the need for libraries to raise dialogs when an error arises when 
not asked to do so (which is a bad thing).
* There have been performance hits for using exceptions in the past with older 
compiler versions, but this may not be so bad anymore. Apparently, the g++ 
compiler had problems in the past with bloated, slow code, but these issues 
appear to have been resolved. Also, one needs to remember that programs must 
work right before they work fast (note I am not trying to justify bad 
programs design that could theortically result in routines taking decades to 
complete).

* Much rework in KDE needs to be done to use QT4, so given all the other 
breaking changes, this is a good time to introducing broader use of 
exceptions in KDE if at all.

This is what I consider to be Big Reason 1 for using exceptions in KDE libs:
* Being confronted with an exception is actually a good thing: One can neither 
ignore it nor can one ignore the problem that lead to the exception. This 
means unexpected conditions are going to be discovered early in testing 
instead of lingering on as hard-to-discover problems arising from the 
developer having neglected to or opting not to test a return code. This leads 
to shorter test/bug-reporting/bug-fixing turnaround times, more robust code, 
and most of all Happy KDE Users.

And this is what I consider to be Big Reason 2 for using exceptions in KDE4 
libs:
* Supporting exceptions from the libs will make KDE an even more appealing 
platform for the many developers already experienced with Java and .NET (and 
there are lots of them), resulting in a wider acceptance of KDE and more 
applications developed for it. I don't think the lack of established 
procedures for error handling and going back to error codes and checking 
whatever the last error message is going to attract large numbers of 
developers to the KDE platform.

There is No Technical Reason for Not Using Exceptions in Qt:

There was confusion in the discussions on whether Qt supports exceptions. To 
clear that up, I contacted Trolltech on the subject. Here is a summary of the 
answer I got:

* Qt itself does not throw exceptions but does propagate them from the OS and 
user code (though one contributor to a mail thread reporting finding a couple 
of exceptions being used within Qt in event handling code--I am not sure in 
which version).

* Exceptions can be used in Qt as normal in C++, but extra steps need to be 
taken to throw exceptions inside a slot. When throwing exceptions inside a 
slot:
  - Subclass QApplication.
  - Reimplement QApplication::notify()
  - Install a try/catch block around the call of the base class
    implementation.

For more info see:
http://doc.trolltech.com/3.3/qapplication.html#notify
http://doc.trolltech.com/4.0/qcoreapplication.html#notify


Prerequisites for the Successful, Widespread Introduction of 
Exceptions in KDE4:

* Good, discoverable guidelines for the proper use of exceptions. There are 
times when they should not be used and there are wrong ways to use them. For 
example:
  - Don't call functions that raise exceptions from destructors.
  - I expect special note would need to be made regarding use of exceptions
    in threads outside of the main program thread.
  - Exception specifications bring their own set of problems and maybe 
    should not be used (too restrictive, application termination under
    unanticipated runtime conditions) and should likely be avoided.
  - Proper mechanisms are needed for cleaning up open resources upon 
    catching exceptions.
* Documentation on the exceptions thrown from libraries.
* A base exception class with the necessary infrastructure for getting the 
exception's message. I don't think throwing arbitrary objects as exceptions as 
C++ allows is a good idea given the confusion that would result on the 
catching end.
* A core set of well-known exceptions so not everyone needs, for example, to 
create their own "FileNotFoundException".
* Guidelines on proper catching and propagation of exceptions.
* Guidelines on the naming of exceptions, especially those thrown from 
libraries are needed. This facilitates writing code without an IDE as the 
names are self-explanatory.

This may seem like bureaucratic overhead, but it is actually for a good 
reason:
* Having guidelines and core exception classes puts all developers, within KDE 
and without, all on the same page, facilitating communication, and resulting 
in consistent approaches to error handling.
* Not having the guidelines results in:
  - Developers re-inventing the wheel with respect to error handling
    (i.e., the status quo).
  - Confusion resulting in compromised design and bugs.
  - Long e-mail threads that rehash the same issues over and over.
* Exceptions make robust code easier to write.
* Code maintenance is improved as all applications handle errors in a similar 
fashion. This makes it easier for someone to jump into new code who is 
already familiar with how code is written for KDE.

Open Issues:
* There may be problems with exceptions working properly on some platforms 
upon which KDE runs (e.g., MacOS X).
* Packagers may be unclear as to whether the Qt they are packaging has been 
built so as to support exceptions.

Some references added to the thread:
* A discussion on error handling issues:
  http://www.objectarchitects.de/arcus/cookbook/exhandling/
* OpenQuasar site (in German): http://www.openquasar.de/de/quasar/index.html

What is not Disputed in the Recent Email Threads on Exceptions in KDE:
* There appears to be no real issue in the discussions with using exceptions 
with one's own application code (i.e., the exceptions are thrown and caught 
within the application), other than concerns about performance and problems 
with exceptions being thrown during destructor calls (which should not occur 
according to the standard). 

Thanks again to all,

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]