ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@apache.org>
Subject Re: C++ exception handling strategy.
Date Tue, 02 Jun 2015 07:38:15 GMT
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

> 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.

View raw message