Unexpected exception hierarchy in Poco

A general discussion forum.
Posts: 89
Joined: 08 Nov 2010, 17:29

Unexpected exception hierarchy in Poco

Postby marlowabnp » 27 Aug 2011, 13:38


I am just starting to use Poco for a small project of my own. I am using it to start processes. I had a look at what happens when the Process::launch function fails to launch the process and I see that it throws Poco::SystemException. I see that there are a number of Poco exceptions, logic error, runtime error, assertion failure. Initially I thought this was very good. Then I noticed that they all inherit from Poco::Exception which inherits from std::exception. IMHO this is not so good. Here's why I think this:-

My gut reaction on learning that launch errors via an exception was to catch std::runtime_error. But this won't work because Poco::SystemError does not inherit from std::runtime_error. In fact no Poco exceptions inherit from this. The std exception hierarchy is not used. Even Poco::LogicException does not inherit from std::logic_error.

In the past I would not have cared about this very much, but now I have been working on a certain software project based on Windoze I have come to a different view. The project uses a home-grown maths library that can crash with arithmetic exceptions (divide by zero, overflow etc) and can crash with core dumps due to array subscript errors, references through null pointers etc. These errors are never going to be fixed. Instead, a microsoft feature known as Structured Exception Handling (SEH) is use. SEH turns these programmer errors into exceptions that inherit directly from std::exception. When one runs a function that handles any error by throwing an exception, it is useful to distinguish such errors from the ones that can come via SEH. So I tend to trap and handle std::runtime_error and let the SEH ones continue upward (where hopefully they will result in the termination of the program).

So it is very useful to be able to to distinguish between std::runtime_error and std::exception. But Poco does not let me do this, even though it has exception classes that make it look like there is such a distinction. Unfortunately the distinction is only within the Poco library and its exceptions; it is not carried through to the use the exception hierarchy in the standard.

Please, can someone explain why Poco exceptions do not follow the exception hierachy in the standard?


Andrew Marlow

Posts: 89
Joined: 08 Nov 2010, 17:29

Re: Unexpected exception hierarchy in Poco

Postby marlowabnp » 05 Jan 2012, 11:55

I would really appreciate an answerr to this question please.

Posts: 40
Joined: 03 Dec 2011, 18:48

Re: Unexpected exception hierarchy in Poco

Postby codecandy2k » 05 Jan 2012, 13:24

Because that's the only way that makes sense for a hierarchy of Poco exception classes, which are richer than std exception classes. Poco::RuntimeException can't derive from both std::runtime_exception and Poco::Exception, because it will result in a mess with multiple inheritance paths back to std::exception. If Poco::Exception didn't derive from std::exception, then users that want to catch all exceptions wouldn't be able to catch a Poco::Exception from a std::exception handler. If Poco::RuntimeException derived from std::runtime_exception and not Poco::Exception, then users that want to catch Poco::Exceptions wouldn't be able to catch Poco::RuntimeException without a separate handler.

If you want to let those SEH-exceptions bubble upwards, then catch them and re-throw them.

Or catch std::runtime_exception and Poco::Exception, and let std::exception bubble up.

Or actually catch them and handle them gracefully instead of hoping they will result in an application termination.

Posts: 1268
Joined: 11 Jul 2006, 16:27
Location: Austria

Re: Unexpected exception hierarchy in Poco

Postby guenter » 09 Jan 2012, 10:57

codecandy2k said it correctly.

Return to “General Discussion”

Who is online

Users browsing this forum: No registered users and 2 guests