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. |
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. > |
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. >> > |
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. > >> > > > > |
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. 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. >>> |
Free forum by Nabble | Edit this page |