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.
