Completion of error handling

Markus Elfring Markus.Elfring at
Sun Nov 23 12:20:50 GMT 2008

Giancarlo Niccolai schrieb:
> - They are are informative. Just provide debug informations besides
> your programs, and you'll have an immediate and accurate diagnosis of
> what happened. If you need more, let the system to generate a core
> dump, and you'll have even the whole context of the problem. Compare
> this with what happen with an uncaught C++ exception or with an
> ill-handled error (i.e. check-correct-but-no-log).

If C++ exceptions would be supported by the K desktop environment
implementation, more valuable informations could also be collected in a
data structure that was designed for this purpose. A second attempt
would also become possible after a few resources were freed.

We need to distinguish for consequences by null and dangling pointers
that will result in a segmentation violation (SIGSEGV).

> You don't want crashes either when the availability of the software is
> critical (i.e. in the OS or vital systems of an aircraft driving
> software). But KDE hardly needs to meet those requirements.

I see this detail also as a matter for software development style.

> The problem is that, often, the line between a programming error and a
> runtime error not related directly with inherent errors in the code is
> very subtle. In example, having 0 returned from a malloc(). If this
> happens because you went off-by-two in a size calculation and you're
> asking 4GB of memory instead of 1 byte, it's your problem.

Nice example.

> Also, any recovery or notification action would probably require some
> memory... which you don't have anymore.

Error/exception handling will always need some memory during processing
of its own data structures.

>> Visit to unsubscribe <<

More information about the kde-core-devel mailing list