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