Nobody cares about your stack trace!

January 21, 2007 at 23:44 · Filed under Java, .NET, Web Services, Spring-WS

Some Web service stacks offer an option to send any server-side stack trace over to the client, as part of a <faultDetail/> block. Axis 1 does it, and it seems like the JAX-WS reference also offers this feature. Presumably, this makes it easier to debug the service from the client side.

Let me explain why I think that there is a big difference between a SOAP Fault and an exception, and why I don’t offer this feature in Spring-WS:

Let’s say I call a public Web service to get a stock quote. Instead of the result, I might get a SOAP Fault as a reponse, which means something went wrong. In SOAP 1.1, a Fault contains four elements, the first two of which are required:

  1. a code (a qualified name)
  2. a string
  3. an actor, and
  4. a detail (which can contain any number of xml elements)
A Java or .NET Exception, on the other hand, has just two elements:
  1. a string message, and
  2. a stack trace
Notice the difference between the two? Of course, you can use the exception message as the fault string, and you can create some kind mapping between the exception class and the code, but that’s your mapping. There is no standard, interoperable way to write stack traces in faults, mostly because stack traces can only be found in Java, but not in C, for instance. And Web services are all about interoperability.

Back to the stock quote: imagine the Web service is not written in Java, but in C, which means we cannot send any stack trace as part of the fault. So what do we send in order to facilitate debugging on the client side? Do we attach the core dump ;) ?

There’s a simple lesson here: it only makes sense to use Web service technology where the client isn’t interested to the language of the server. If you really want to see the stack trace on the client-side, use Java RMI. If you want to invoke a method on a class written in another language, use CORBA or Hessian. If you want to do XML messaging, use SOAP.

7 Comments

  1. Dan Diephouse said,

    January 22, 2007 @ 6:03

    I think we need to distinguish between two things here. First, creating an exception on the client which mirrors the server like RMI would. Second, sending along more debugging information in the form of a stack trace.

    There is probably a user a day on the xfire mailing list who doesn’t seem to comprehend that a stack trace occurred on the server side because they didn’t check their logs. I don’t think we should be reconstructing the exception on the other side, but it probably isn’t that bad to just print it to stdout. It certainly would save me from writing a few emails!

    Though I do have mixed feelings about it as people often forget to turn that extra debugging off in production.

  2. Tim Vernum said,

    January 22, 2007 @ 8:46

    I’m not sure it’s as simple as all that…

    I can think of 4 web services configs that I’m currently running where I would probably turn on a “convert exception to fault” type feature.
    Only 1 of those is using SOAP, but in each case that’s an implementation detail.

    The SOAP service is facilitating a .NET client talking to a Java server between two very closely related business units. If something goes wrong and our service triggers an exception then I would prefer the guys on the other end get as much information as possible, as it may be that they caused it (by passing in some combination of data that the service did handle cleanly), or it may be that our database went down and having an SQLException (or some runtime wrapper around it) and that will tell them that it’s our problem and there’s no point them trying to work out if the fault is in the client.

    Now, all those things can be dealt with by mapping all the errors explicitly. But that’s a lot of work, for not much gain. Or we can put our own exception catching block at the top of our service and do the SOAP-fault mapping ourself, but that just results in every project duplicating the same code that could have been in Spring-WS.

    For our services that have multiple clients with various implementation languages, the exposing of the stack trace isn’t something I’d do. But for simple inter-op between two independant applications it seems to me like the simplest path to exposing the fault.

    We’re not expecting exceptions - that’s why they’re exceptions - but if they occur you need some way to report an error. For some use cases a simple “general server error” is appropriate. But in other cases the more information you can push out to the client the faster it will be resolved.

  3. Steve Loughran said,

    January 22, 2007 @ 13:23

    I wrote a lot of the stack trace code in AxisFault, and stand by my decisions.

    1. Axis 1.x doesnt send a stack trace over the wire unless you set a flag saying you are a dev system. That wasnt just because end users dont care about stack traces -if you are a developer trying to integrate with someone elses system, quiite often you do. It was mainly for security reasons: I dont want to expose internals unless I have to.

    2. I also added the stuff that says the name of the host at fault. Because when you have an 8 way server, you like to know that its server 3 failing al requests, not “one request in 8 is failing”. Again, I think you can strip it if you are paranoid.

    3. Did I mention I add http error codes and strings in somewhere too?

    I never try and turn soap faults back into native faults; that is silly. the stack trace is just an extra bit of debugging detail, and very nice too.

  4. Arjen Poutsma said,

    January 23, 2007 @ 0:45

    @Steve,

    Fair enough, the code in Axis seems to be well thought out, and seems to be helpful for debugging purposes. I’m still not entirely convinced, though ;) .

  5. Mats Helander said,

    January 23, 2007 @ 8:39

    Hi Arjan,

    Shouldn’t the same idea apply to any black box in principle? I won’t be able to debug your web service and I won’t be able to debug your black box, closed source component…but I might be able to mail you the stack trace so that you can debug it more easily!

    That C doesn’t offer a stack trace is more of a problem with C that shouldn’t be allowed to “drag down” a “real” language with it? So, I don’t agree :-)

    /Mats

  6. Stefan Tilkov's Random Stuff said,

    January 31, 2007 @ 8:39

    Interview with Arjen Poutsma

    The Spring framework is very popular among Java developers as a more lightweight alternative to “enterprise” frameworks. One of the newest additions is the Spring Web Services subproject, which according to the Web site “is focused on…

  7. Spring Framework said,

    February 1, 2007 @ 22:19

    Interview: Arjen Poutsma on Spring Web Services

    InfoQ’s Stefan Tilkov talks to Spring Web Services creator Arjen Poutsma about Web services in general

RSS feed for comments on this post