Java/.NET web service interoperability issue regarding checked exceptions

Using web services as integration technology is an obvious choice when service-orienting your companys IT architecture, especially when having a mixed Java and .NET environment. One strategy many companies choose is to package business logic in Java-based web services while developing web user interfaces on the .NET platform.

The problem

There is one interoperability issue that I'll like to shed some light on, and that is "checked exceptions". Checked exceptions is userdefined exceptions. Java supports this construct whereas C# doesn't. The C# development team have chosen to exclude checked exceptions by design (why? -> pls read the interview with the lead C# architect Anders Hejlsberg at http://www.artima.com/intv/handcuffs.html). This imposes a risk of having unhandled exceptions. A java-based web service may throw checked exceptions that the .NET-based client is unaware of. The .NET client developer needs to manually analysis the WSDL file to see what type of exceptions the web service method may throw. This is a tedious and error-prone way to work compared to the Java/Axis that autogenerates a complete interface including exceptions in object-form on the client side.

The solution

C# doesn't support checked exceptions by design, but Windows Communication Foundation supports automatic analysis of the WSDL-file when creating the proxy on the client (you must use svcutil.exe, not wsdl.exe. Svcutil.exe is default in Visual Studio 2008, but not in 2005. Or run on the command line). Exceptions are serialized in objects that can be analyzed and handled on the client without needing to parse XML-strings for error codes and messages. The exceptions are catched in regular try-catch blocks just as any other .NET Exception. This way, you get type safe userdefined exceptions. You'll also get the "intellisense" in Visual Studio on exception objects.

© Copyright 2008, Tomas Elfving