At this point in my programming experience, I realize how spoiled I am to have exception handling available in most languages being used today (C++, .Net, Java, etc), at least in comparison to C. I am getting ready to take an advanced C course and has me really thinking those terms in comparison to my current paradigm.

In C, it's up to the programmer to prevent errors from ever occuring in the first place, which is quite daunting for anybody who is used to exception handling. It has occured to me that any language that I have come across that has exception handling happens to be object oriented. The first object oriented language to have exception handling, at least to my knowledge, is C++ which is sort of an evolution of C. (please correct me if I am wrong)

With that said, is there something about the object oriented nature of a language that allows exception handling, or was exception handling added as a feature as object oriented languages really started becoming a commonplace? What is that C lacks that to say, C++, in machine code that makes excpetion work?

I found this post about how exception handling works under the hood, but not sure how that information applies to my question (ie, does C lack notifications, continuations, etc?). Thanks in advance.

C lacks nothing in machine code, and exception handling was and is commonplace in C with setjmp and longjmp.

The reason for the complete lack of a language-level feature in purely procedural languages is that exception handling is identical to setjmp when no destructors need to be called. Exception handling has been around before in exotic languages, but never caught on because it was purely syntactic sugar. However, once destructors entered the scene and stack unwinding became necessary, language-level support became necessary and exception handling was widely implemented as part of the language.

The project I'm currently working on requires me to code up the android portion of a cross platform program implementation.

A core set of functionality is built and included in my app through android-ndk. I've found that any exception/crash which happens in the native code is only reported now and again at best. When an error occurs I get one of the following behaviours:

• A stacktrace / memory dump occurs and is written to the log file. The program disappears (no indication is given on the device as to why suddenly the app is no longer there).
• No stacktrace / dump or other indication is given that the native code has crashed. The program disappears.
• The java code crashes with a NullPointerException (usually in the same place per native code exception which is a massive pain). Usually causing me to spend quite a while trying to debug why the Java code has thrown an error only to discover the Java code is fine & the native code error has been entirely masked.

I can't seem to find any way to "insulate" my code against errors which occur in native code. Try/catch statements are resoundingly ignored. Apart from when my code is fingered as the culprit I don't even get a chance to warn the user than an error has occurred.

Can someone please help me out as to how to respond to the situation of crashing native code?

I used to have the same problem, it is true that in android (inside any VM in general when executing native code) if you throw a C++ exception an this one is not cached the VM dies (If I clearly understood I think it is your problem). The solution I adopted was to catch any exception in C++ and throw a java exception instead using JNI. The next code it is a simplified example of my solution. First of all you have a JNI method that catches a C++ exception and then in the try clause the Java exception is annotated.

JNIEXPORT void JNICALL Java_com_MyClass_foo (JNIEnv *env, jobject o,jstring param)
{
    try
    {
        // Your Stuff
        ...
    }
    // You can catch std::exception for more generic error handling
    catch (MyCxxException e)
    {
        throwJavaException (env, e.what());
    }
}


void throwJavaException(JNIEnv *env, const char *msg)
{
    // You can put your own exception here
    jclass c = env->FindClass("java/lang/RuntimeException");

    if (NULL == c)
    {
        //B plan: null pointer ...
        c = env->FindClass("java/lang/NullPointerException");
    }

    env->ThrowNew(c, msg);
}

Note that after a ThrowNew, the native method does not abruptly terminate automatically. That is, control flow returns to your native method, and the new exception is pending at this point. The exception will be thrown after your JNI method is finished.

I hope it was the solution you are looking for.