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

List:       kde-devel
Subject:    Re: C++ exceptions
From:       Vladimir Prus <ghost () cs ! msu ! su>
Date:       2005-12-06 7:10:21
Message-ID: dn3dgs$de5$1 () sea ! gmane ! org
[Download RAW message or body]

Thiago Macieira wrote:

> Vladimir Prus wrote:
>>1. Add "try/catch" in each of 30 slots
>>2. Introduce 30 new function and use heavy template magic, or macros, to
>>call those 30 new function from slots with added try/catch.
> 
> Let me make it clear: exceptions are not to trasverse KDELibs and Qt code.
> If any of your 30 slots calls a function that may throw an exception, you
> MUST catch it in the slot.

Yes, I know that's the case with current Qt/KDE. That's why I raise the
point in the first place.

> Allowing the exception to reach the Qt signal/slot mechanism is bound to
> fail and, quite possibly, core dump.
> 
>>An ideal solution would be to have some base KException class, and a
>> signal KApplication::onException(KException&) that I can connect to for
>> error reporting. But implementing that would require lots of try/catch
>> inside kdelibs, so I'm not sure that's workable.
> 
> I don't think exception handling in kdelibs code is something you can
> expect realistically. For one thing, Qt 4 has been released and it does
> not use exceptions. So KDE Library code will probably follow suit.
> 
> That's why KDE libraries are compiled with -fno-exceptions. And, as I said
> before, specific libraries and applications can turn exceptions back on,
> if they so need it.

Yes, but without global catch inside kdelibs this will be extremely
inconvenient. Original poster most likely wanted to know how easy is it to
use exceptions in some application -- it's possible, but with a lot of
extra fuss.

- Volodya


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