C++ Exception Handling

[rafm]

Is it possible to handle C++ exception in Qtopia applications?

I compile my application without the "-fno-exceptions" flag, but nevertheless the execeptions do not seem to work. The application aborts instead of catching the exception.

[lpotter]

Qt/E for Qtopia is compiled without exceptions.

[rafm]

Qt/E for Qtopia is compiled without exceptions.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=104343\"][{POST_SNAPBACK}][/a][/div]

Does it mean that I cannot use exceptions at all, or I must catch exception before the QT event handler?

I am working on a GUI application that should handle exceptions within a single method before the control is returned to the QT event handler. I would expect that, if everything is compiled correctly, exceptions should be handled within my methods.

[rafm]

Does it mean that I cannot use exceptions at all, or I must catch exception before the QT event handler?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=104347\"][{POST_SNAPBACK}][/a][/div]

I did some research and I can answer this question myself. Exceptions work as long as neither -fno-exceptions nor -fno-rtti are specified (exception handling uses rtti internally). However if -fno-rtti is missing, compilation fails when linking with the QT. So it seems that GUI applications  can not use exceptions. That's a pitty, since error handling without exceptions needs quite a lot of work and results in not so clean code.

Is there any way around to use both exceptions and the QT? I am curious what was the motivation to disable exceptions in the Qt/E.

[lpotter]

Exceptions have a large overhead, and create larger binary and memory requirements.

I find it is actually easier to deal with errors without exceptions, and it takes more work and lines of code try catch statements then simply checking for error codes and such.

Remember, Qtopia and Qt/E are run in limited memory spaces.

From http://www.pnp-software.com/ObsFramework/d...tionIssues.html

As expected, the most important gain arises from the use of the -fno-rtti and -fno-exceptions  options. The -fno-rtti option removes all code and data related to the use of the C++ run-time type information mechanism. The -fno-exceptions removes all code and data related to the use of the C++ exception mechanism (recall that the framework classes use a very restricted subset of the C++ language that does not use either the RTTI or the exception mechanisms). Taken together, these two options basically eliminate the overhead associated to the use of the C++ language.

[Mickeyl]

For the records... a lot of computer scientists agree that structured exception handling is to be preferred over checking return codes or global variables. See also http://www.nedbatchelder.com/text/exceptions-vs-status.html for some more background on that matter.

I agree that the particular C++ exception handling implementation may be too bloated for the usage in resource constraint environments but please don't make that conclusion for structured error handling in general. I've read papers that prove that well written structured exception handling code can lead to even smaller code than the classic return code / global value style.

[lpotter]

I've read papers that prove that well written structured exception handling code can lead to even smaller code than the classic return code / global value style.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=104679\"][{POST_SNAPBACK}][/a][/div]

I would like to see proof...

[Dobby]

Probably digging up this topic a bit as it hasn't seen activity since the end of last year but I'd like to say that while it may add some overhead in terms of memory exceptions only slow performance when invoked. In other words when an exception is actually thrown.

And yes it is considered better design to use exceptions. Countless times I've seen code greatly simplified by the use of them. Whether this out weighs the overhead I can't vouch for the Zaurus but I've been using exceptions for the last ten years and as this was around the time of the 486 I don't think it's really that big a problem for the xscale.

So now I've got that off my chest has anyone managed to get exceptions working?  Not that I've tried yet I'm just researching at the moment.