java vs .net exception model

Lately I’ve been going back and forth between java and .NET and trying to keep as many of the architectural constructs the same because of the similarities in IL representation and concepts .... plus it’s just great to have analogous ported concerns to work with.

One issue I have not been able to get past is the throwable model between the two.

Java:
<code>
public class RandomClass
{
        public void doSomething throws Exception
        {
                // do something
        }
}
</code>

.NET/C#
<code>
public class RandomClass
{
        public void DoSomething
        {
                // do something
                // note the lack of a need to define the exception stack
        }
}
</code>

This poses issues for various architectures and/or frameworks when developed in one ported to another. It’s not a huge issue b/c you can always introduce an ExceptionHandler into java as a setter on the object. But that’s not the point of this blog. The point of this blog is the seeming why this is the case.

Java’s runtime is developed in C which is a language that does not have a throwable architecture for runtime exceptions; hence, why in the JNI interface the exception isn’t thrown it’s more set and evaluated at the end of the execution of the method when returning to the Java runtime.

<code>
JNIEXPORT jvoid JNICALL example_throw(JNIEnv *env, jobject obj)
{
jclass Exception = env->FindClass("java/lang/Exception");
env->ThrowNew(Exception,”some random exception);
}
</code>

It’s after the end of the execution of the throw method that the exception is actually detected.

Conversely the .NET runtime is implemented in C++ ... which has an inherent throwable architecture. This makes sense why there doesn’t have to be metadata around what the exception hierarchy is that is being thrown.

......