C++ exception handling strategy.

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

C++ exception handling strategy.

Vladimir Ozerov
Igniters,

In Java our API extensively use exceptions to signal faulty conditions. The
same technique must be applied somehow to C++ API as well.

The most obvious solution for our Java minds is to simply throw exceptions
in C++ as well. But this solution doesn't seem to be valid for C++ world:
1) User will inject varoius resources into our lib (e.g. allocators,
serializers, closures). Throwing excpetino will make memory management
extremely tough from user perspective.
2) Throwing exceptions across module boundaries is considered to be a bad
practice from both portability and usability standpoints (e.g. we do not
want user app to crash due to, say, CachePartialUpdateException).
3) Exceptions might be disabled explicitly for some apps.

I propose to use the same approach as WinAPI, JNI and lots other libraries
do: never throw exceptions, but rather have a separate function to check
for previous error. This function will return the last error occurred in
the thread (if any).

References:
http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/functions.html#wp5234
(functions ExceptionOccurred, ExceptionCheck)
https://msdn.microsoft.com/en-us/library/windows/desktop/ms679360%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396

Please share your thoughts regarding the matter.

Vladimir.
Reply | Threaded
Open this post in threaded view
|

Re: C++ exception handling strategy.

Denis Magda
Vladimir,

One more way is to return an error code from a function.
Example,
int socket_write(socket *ptr, byte *buf, int buf_len);
The function will return actual number of bytes written or -1 in case of
error 1, -2 in case of error 2, etc..
Such approach is widely used by Java ME at the native level, Brew MP and
many other platforms.

Next, Apple Core Foundation returns error through a pointer passed to a
function when it's impossible to return an error code as a return parameter.
Example,
int error;
do_something(task, &error);
if (error == -1)

--
Denis

On 6/1/2015 11:42 AM, Vladimir Ozerov wrote:

> Igniters,
>
> In Java our API extensively use exceptions to signal faulty conditions. The
> same technique must be applied somehow to C++ API as well.
>
> The most obvious solution for our Java minds is to simply throw exceptions
> in C++ as well. But this solution doesn't seem to be valid for C++ world:
> 1) User will inject varoius resources into our lib (e.g. allocators,
> serializers, closures). Throwing excpetino will make memory management
> extremely tough from user perspective.
> 2) Throwing exceptions across module boundaries is considered to be a bad
> practice from both portability and usability standpoints (e.g. we do not
> want user app to crash due to, say, CachePartialUpdateException).
> 3) Exceptions might be disabled explicitly for some apps.
>
> I propose to use the same approach as WinAPI, JNI and lots other libraries
> do: never throw exceptions, but rather have a separate function to check
> for previous error. This function will return the last error occurred in
> the thread (if any).
>
> References:
> http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/functions.html#wp5234
> (functions ExceptionOccurred, ExceptionCheck)
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms679360%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396
>
> Please share your thoughts regarding the matter.
>
> Vladimir.
>

Reply | Threaded
Open this post in threaded view
|

Re: C++ exception handling strategy.

Branko Čibej
If you don't want to use exceptions, you'll still have to write
exception-safe code: depending on the environment, exceptions can be
thrown from standard library methods.

In general, though, I agree that using exceptions for error handling is,
whilst on the surface an obvious decision, in practice quite complex.

I very strongly suggest not using any kind of global error state. Such
designs (see: POSIX/C errno; Windows' GetLastError; etc.) are extremely
flaky in a multi-threaded environment and hard to get right. Instead,
make all calls that can fail return a uniform error code; in C++, this
can be an enum, but it's even better to use a struct so that you can
chain/combine multiple error codes if necessarty. See, for example.
svn_error_t at line 178 in

   
http://svn.apache.org/viewvc/subversion/trunk/subversion/include/svn_types.h?view=markup

and the various manipulation functions declared in svn_error.h in the
same directory. In C++ this can be even easier to do than in C, from the
memory management point of view.

-- Brane


On 01.06.2015 16:01, Denis Magda wrote:

> Vladimir,
>
> One more way is to return an error code from a function.
> Example,
> int socket_write(socket *ptr, byte *buf, int buf_len);
> The function will return actual number of bytes written or -1 in case
> of error 1, -2 in case of error 2, etc..
> Such approach is widely used by Java ME at the native level, Brew MP
> and many other platforms.
>
> Next, Apple Core Foundation returns error through a pointer passed to
> a function when it's impossible to return an error code as a return
> parameter.
> Example,
> int error;
> do_something(task, &error);
> if (error == -1)
>
> --
> Denis
>
> On 6/1/2015 11:42 AM, Vladimir Ozerov wrote:
>> Igniters,
>>
>> In Java our API extensively use exceptions to signal faulty
>> conditions. The
>> same technique must be applied somehow to C++ API as well.
>>
>> The most obvious solution for our Java minds is to simply throw
>> exceptions
>> in C++ as well. But this solution doesn't seem to be valid for C++
>> world:
>> 1) User will inject varoius resources into our lib (e.g. allocators,
>> serializers, closures). Throwing excpetino will make memory management
>> extremely tough from user perspective.
>> 2) Throwing exceptions across module boundaries is considered to be a
>> bad
>> practice from both portability and usability standpoints (e.g. we do not
>> want user app to crash due to, say, CachePartialUpdateException).
>> 3) Exceptions might be disabled explicitly for some apps.
>>
>> I propose to use the same approach as WinAPI, JNI and lots other
>> libraries
>> do: never throw exceptions, but rather have a separate function to check
>> for previous error. This function will return the last error occurred in
>> the thread (if any).
>>
>> References:
>> http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/functions.html#wp5234
>>
>> (functions ExceptionOccurred, ExceptionCheck)
>> https://msdn.microsoft.com/en-us/library/windows/desktop/ms679360%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396
>>
>>
>> Please share your thoughts regarding the matter.
>>
>> Vladimir.
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: C++ exception handling strategy.

Vladimir Ozerov
Denis, Brane,

Thank you for your inputs. Agree that thread-local approach is far from
ideal, especially because its default behavior is silent error ignoring.
What if we define an error handler interface which user can inject into the
grid? This handler will be notified whenever error occurrs.

On Tue, Jun 2, 2015 at 8:48 AM, Branko Čibej <[hidden email]> wrote:

> If you don't want to use exceptions, you'll still have to write
> exception-safe code: depending on the environment, exceptions can be
> thrown from standard library methods.
>
> In general, though, I agree that using exceptions for error handling is,
> whilst on the surface an obvious decision, in practice quite complex.
>
> I very strongly suggest not using any kind of global error state. Such
> designs (see: POSIX/C errno; Windows' GetLastError; etc.) are extremely
> flaky in a multi-threaded environment and hard to get right. Instead,
> make all calls that can fail return a uniform error code; in C++, this
> can be an enum, but it's even better to use a struct so that you can
> chain/combine multiple error codes if necessarty. See, for example.
> svn_error_t at line 178 in
>
>
>
> http://svn.apache.org/viewvc/subversion/trunk/subversion/include/svn_types.h?view=markup
>
> and the various manipulation functions declared in svn_error.h in the
> same directory. In C++ this can be even easier to do than in C, from the
> memory management point of view.
>
> -- Brane
>
>
> On 01.06.2015 16:01, Denis Magda wrote:
> > Vladimir,
> >
> > One more way is to return an error code from a function.
> > Example,
> > int socket_write(socket *ptr, byte *buf, int buf_len);
> > The function will return actual number of bytes written or -1 in case
> > of error 1, -2 in case of error 2, etc..
> > Such approach is widely used by Java ME at the native level, Brew MP
> > and many other platforms.
> >
> > Next, Apple Core Foundation returns error through a pointer passed to
> > a function when it's impossible to return an error code as a return
> > parameter.
> > Example,
> > int error;
> > do_something(task, &error);
> > if (error == -1)
> >
> > --
> > Denis
> >
> > On 6/1/2015 11:42 AM, Vladimir Ozerov wrote:
> >> Igniters,
> >>
> >> In Java our API extensively use exceptions to signal faulty
> >> conditions. The
> >> same technique must be applied somehow to C++ API as well.
> >>
> >> The most obvious solution for our Java minds is to simply throw
> >> exceptions
> >> in C++ as well. But this solution doesn't seem to be valid for C++
> >> world:
> >> 1) User will inject varoius resources into our lib (e.g. allocators,
> >> serializers, closures). Throwing excpetino will make memory management
> >> extremely tough from user perspective.
> >> 2) Throwing exceptions across module boundaries is considered to be a
> >> bad
> >> practice from both portability and usability standpoints (e.g. we do not
> >> want user app to crash due to, say, CachePartialUpdateException).
> >> 3) Exceptions might be disabled explicitly for some apps.
> >>
> >> I propose to use the same approach as WinAPI, JNI and lots other
> >> libraries
> >> do: never throw exceptions, but rather have a separate function to check
> >> for previous error. This function will return the last error occurred in
> >> the thread (if any).
> >>
> >> References:
> >>
> http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/functions.html#wp5234
> >>
> >> (functions ExceptionOccurred, ExceptionCheck)
> >>
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms679360%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396
> >>
> >>
> >> Please share your thoughts regarding the matter.
> >>
> >> Vladimir.
> >>
> >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: C++ exception handling strategy.

Branko Čibej
In reply to this post by Branko Čibej
On 02.06.2015 07:48, Branko Čibej wrote:

> If you don't want to use exceptions, you'll still have to write
> exception-safe code: depending on the environment, exceptions can be
> thrown from standard library methods.
>
> In general, though, I agree that using exceptions for error handling is,
> whilst on the surface an obvious decision, in practice quite complex.
>
> I very strongly suggest not using any kind of global error state. Such
> designs (see: POSIX/C errno; Windows' GetLastError; etc.) are extremely
> flaky in a multi-threaded environment and hard to get right. Instead,
> make all calls that can fail return a uniform error code; in C++, this
> can be an enum, but it's even better to use a struct so that you can
> chain/combine multiple error codes if necessarty. See, for example.
> svn_error_t at line 178 in
>
>    
> http://svn.apache.org/viewvc/subversion/trunk/subversion/include/svn_types.h?view=markup
>
> and the various manipulation functions declared in svn_error.h in the
> same directory. In C++ this can be even easier to do than in C, from the
> memory management point of view.
Here's a quick prototype of what I meant by "C++ even easier than in C":
An error class that has built-in protection against ignoring returned
errors.


> On 01.06.2015 16:01, Denis Magda wrote:
>> Vladimir,
>>
>> One more way is to return an error code from a function.
>> Example,
>> int socket_write(socket *ptr, byte *buf, int buf_len);
>> The function will return actual number of bytes written or -1 in case
>> of error 1, -2 in case of error 2, etc..
>> Such approach is widely used by Java ME at the native level, Brew MP
>> and many other platforms.
>>
>> Next, Apple Core Foundation returns error through a pointer passed to
>> a function when it's impossible to return an error code as a return
>> parameter.
>> Example,
>> int error;
>> do_something(task, &error);
>> if (error == -1)
>>
>> --
>> Denis
>>
>> On 6/1/2015 11:42 AM, Vladimir Ozerov wrote:
>>> Igniters,
>>>
>>> In Java our API extensively use exceptions to signal faulty
>>> conditions. The
>>> same technique must be applied somehow to C++ API as well.
>>>
>>> The most obvious solution for our Java minds is to simply throw
>>> exceptions
>>> in C++ as well. But this solution doesn't seem to be valid for C++
>>> world:
>>> 1) User will inject varoius resources into our lib (e.g. allocators,
>>> serializers, closures). Throwing excpetino will make memory management
>>> extremely tough from user perspective.
>>> 2) Throwing exceptions across module boundaries is considered to be a
>>> bad
>>> practice from both portability and usability standpoints (e.g. we do not
>>> want user app to crash due to, say, CachePartialUpdateException).
>>> 3) Exceptions might be disabled explicitly for some apps.
>>>
>>> I propose to use the same approach as WinAPI, JNI and lots other
>>> libraries
>>> do: never throw exceptions, but rather have a separate function to check
>>> for previous error. This function will return the last error occurred in
>>> the thread (if any).
>>>
>>> References:
>>> http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/functions.html#wp5234
>>>
>>> (functions ExceptionOccurred, ExceptionCheck)
>>> https://msdn.microsoft.com/en-us/library/windows/desktop/ms679360%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396
>>>
>>>
>>> Please share your thoughts regarding the matter.
>>>
>>> Vladimir.
>>>


error.cpp.txt (8K) Download Attachment