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

List:       kde-devel
Subject:    Re: Re: Best Practices or Design Patterns for Error Handling in KDE
From:       Sebastian Stein <seb_stein () gmx ! de>
Date:       2005-11-07 14:58:11
Message-ID: 20051107145811.GA4959 () hpfsc ! de
[Download RAW message or body]

Frans Englich <frans.englich@telia.com> [051107 15:51]:
> >  The question is, does the additional code for exceptions add more code
> > than all the hand-written code doing the error handling manually?
> 
> I think that's a good point, the usual questioning of whether getting 
> primitive on the language level is a win.
> 
> Exception have a performance penalty, but the question is whether that 
> performance gain is noticble during the X number of years an alternative 
> solution is used, and where the drawback of increased code complexity(bugs) 
> is present. Perhaps one should leave low level optimization to Moore's law 
> and ensuring one uses a recent compiler, and instead focus on high 
> quality /code/.

I think the problem is not which technical solution is chosen for error and
exception handling. If exceptions are used - fine. If return values are used
- fine too. However, the important point is to do it a) in a unified way and
 b) capsulate it. This is not done in KDE to best of my knowledge. The
initial poster pointed out that he is looking for patterns or frameworks
handling errors within the KDE code. Till now I don't think his question was
answered sufficiently. I can only answer the question in that way, that
there is no unified way of handling errors in KDE code. Some patterns might
reoccur in some parts of the KDE code (like kdelibs). The only thing we know
for sure is that exceptions are not used.


Sebastian
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]