A problem I have with a lot of the KIO classes is that it decides it
should handle the a problem itself and show the user some annoying
message box, when personally I think KIO should /never/ do anything
with the GUI unless explictly told to do so.

This is the kind of situation where having exceptions would be nice I
think... though it would be possible to design it will without them.

On 11/7/05, Sebastian Stein wrote:
> Frans Englich [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 <<

>


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