How to implement error handling/returning while streaming a message

Question

Say someone calls a web service on a server, the relevant data is being retrieved in batches and the message is being streamed to the client. In the middle of the message some kind of exception is encountered. My current implementation sort of just stops streaming the (in this case soap) message and starts streaming an error message, but obviously the result won't be a valid message or even valid XML.

I considered a few options, none of them seem to make much sense:

• Put all the relevant data in memory and then only stream the message itself.
• Do a double-take, so see if it works out with a fake stream and then do the real stream.
• Stream to a disk first and then use a file input stream to stream to the client

Because this is an implementation for a generic application platform, I do not know how big the messages will be, but I have heard people are using web services in our app platform with gigabytes of data.

As you can see all have serious downsides in terms of memory/disk consumption, speed/resource efficiency or even validity of the data. How would I best implement error handling in this situation? Do I just have to pick the least worst of these options? If so I tend to favor to the current situation where the message is just invalid in cases like these, because it at least doesn't affect the base case where everything is fine.

• 9000: How large are your messages? If these are not outright huge, I'd go with your first approach. The third approach is about as fast, assuming you have a large enough filesystem cache.
• Sebastiaan van den Broek: Thanks, I didn't think to include that. I edited my message. The short answer is that I don't know.
• Bart van Ingen Schenau: If you can't get the error to the client in such a way that the clients can do something with it (like show to the end-user), then you might as well not send an error message at all and just terminate the connection.
• Canadian Luke: What about splitting messages larger than xxx kilobytes, sending messages one at a time manually, and reconstructing on the client?
• Sebastiaan van den Broek: @BartvanIngenSchenau yeah well in this case something might be better than nothing, they can still in some way see the error, it just requires someone to manually look at the logs. It's better than having to call the guys maintaining the server.

Answer 1

If I've understood, you have to apply business logic while streaming down the response, so you may get an error, which need to get forwarded to the client.

In this scenario, as you are composing the xml of the response "on the fly", you may add in the end of the SOAP envelope some fields which tell the client if the response was correct && complete.

In case of error, you can complete the current field (so that the envelope is well formed) and add your error fields at the end of the response.

• Sebastiaan van den Broek: We thought of another variety of this solution by closing the entire message and then adding a standard soap error message afterwards. But since the data is not actually correct we didn't want to give room for mistakes on the client side, i.e. they process an entire soap message that seems correct and then just ignore whatever comes afterwards. Adding custom error fields would be possible but since we're building a generic framework this would be up to the developer that is actually building a web service using our platform. He/she would end up with a WSDL containing those error fields I guess
• Sebastiaan van den Broek: Still thanks for the suggestion and I do think this would be a good solution for a real implementation, just not so much for a generic framework where we don't define the contents of the message ourselves.
• Dan M: You may define a generic "framework" response, which the implementer has to extend with the specific application field. I guess that will be your framework which will handle the build of the SOAP response, so you'll be in control of what the specific application is doing (try/catch handled by the framework). I don't see many other way of addressing your question, other than breaking the channel and leaving the caller wondering what happened :)
• Sebastiaan van den Broek: I thought of that and will consider that, yeah. One of the downsides is that we cater to non-technical people and if they aren't in charge of defining the error fields themselves then they might not always know what to do with it and what to tell the developers implementing the client (which could be any custom code solution) about them and how to act upon them either. But this still might be the favorable solution.
• Dan M: You may give to the implementer an handler which the framework will call in case of error, so you can achieve both the architectural error handling and the application content of that error. (and think of a generic error, in case the implementer is too lazy to write that handler ;) )

Answer 2

How about throwing a SOAP exception from the server side and handling it on client side? This is standard way of handling soap faults.

• Sebastiaan van den Broek: The question is about how to do this in a streaming way. I am already halfway into streaming the message out so I can't suddenly revert that and throw a SOAP exception nicely.
• Low Flying Pelican: Does the exceptions also needs to handle in the stream? You can return a stream as response and if you get an exception you can throw an exception which client can handle easily.