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 <[email protected]> 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. > >> > > > >
