Public Class GeoffAppleby : I need some advice with exceptions.

Navigation

Comments

James Shaw said:

I can't point you at an essay on the reason why, but i would definately say that the web method needs to return normally but with a return code to let you know the outcome. We always use return that derives from a common base class for the result that includes status code and string description for use on the client.

# June 27, 2005 4:54 AM

Geoff Appleby said:

That's the direction I'm leaning in (sadly I'm not even doing that). Currently I've taken the standpont that the last thing we want seen on the client website is an exception message or error page. I've coded the websites (the web service consumers) to directly handle a null result and treat it like 'normal'. It's not often that getting nothing back can't be treated as 'oh, well, it's really meant to have nothing in the list'. or something.

# June 27, 2005 5:57 AM

rsakalley said:

I think an exception should be thrown, and the UI be it web or windows, should handle the exceptions appropriately. Thats the basic, I think is and should be applied even accross boundaries. Morover in my opinion, return messages are a bit clumsy. Exceptions are the elegant solution to an inelegant problem :).

# June 27, 2005 6:36 AM

ewise said:

I would not pass an exception across boundaries. As a consumer of a webservice, I really just need a return code with a friendly message.

Think of it this way, does the consumer really need to know what specific SQL Error occured with the full error info/stack trace that you would get by passing the exception itself? No, especially since they can't debug YOUR code anyway.

Usually my return codes run like this:

Service Unavailable
Invalid Data: <description>
Server Error: Has been logged and the development team has been notified.

That's really all the consumer needs to know... in my very humble opinion.

# June 27, 2005 6:57 AM

Ben Reichelt said:

Yup, eric's right on, I agree.

# June 27, 2005 8:01 AM

pvanooijen said:

I don't think you should pass an exception over the boundary of a webservice. Except for all wise reasons given you should consider that the consumer of the webservices migth not have a clue of what an exception is. It does not have to be a .net client, it doesn't even have to be a Windows client. It could be anything at all. You just don't know.

# June 27, 2005 9:29 AM

Ignat Andrei said:

I think that Exceptions are a more convenient way to handle the error instead of return codes.

On the other hand, if you KNOW ALL the possible exception, you can make an enum - and publish that - and not change ( but this is an idealistic world)

But if you return only an int as return code - you risk the lazy programmer that forgets to intercepts in a switch the "default" -and your error is lost in space.

# June 27, 2005 2:09 PM

Rory Primrose said:

I think that regardless of whether the web service throws exceptions or not, the consumer should handle exceptions. The consumer shouldn't make any assumptions about whether a web service call, or any other library for that matter, will throw an exception. I consider web method calls as untrusted, meaning I don't trust them to not throw exceptions.

I agree with Eric that the details of the exception are not relevant to the client, so if I do throw an exception, I prefer to catch the exceptions on the server and return 'client friendly' exceptions.

Peter also has a valid point that the client may not be .Net. In this case, my best option would be to return an int as it allows for more detail than a boolean. The problem with this is that web services aren't great for this type of interpretation mainly because of a lack of enum support. The consumer would have to know what each return value meant. There could be another web method that returns a message string for the int value, but what if that method fails???? One reason why I don't like this setup is that it relies on another web method to get the message for the int and web methods are slow although it might be the only way to go for non.Net clients.

Generally, my preference is to handle exceptions in the server code and recover as much as possible, but if the server code simply doesn't know what to do with a problem, I would prefer to through an exception. Easy for me to say though as I always expect .Net clients.

# June 27, 2005 6:42 PM

Pierre Grant said:

I asked myself the same questions two weeks ago. We are using "ASP .NET Web services" (VS 2003). I'm relativly new to Web Services and I also thought that throwing exceptions through boundaries was not correct. So I defined an "exception structure" in my output from the Web Method and I catched all exceptions and fill that structure.

From a suggestion from someone, I looked at the SoapException that come with .NET. Here are my conclusions for now:

--> The SOAP specification at W3C has a fault control called «Fault» in which you can specify some properties.

--> The SoapException class translate exceptions to a «Fault» node in the SOAP envelop. Note that SoapException comply to SOAP 1.1. (SOAP 1.2 has different names for the fault properties).

--> Any exception thrown in the Web service is converted to a SoapException before returning to the client. It's better to catch exceptions in the Web method and rethrow a SoapException since it provides more control of the exception content.

So now, I think that my conclusion will be: Throw a SoapException whenever an exception is catch in the Web Method.

We're all .NET actually, but I think that any client that understand SOAP 1.1 protocol will be able to understand the «fault» node from the SOAP envelop.

My next step: I have to check about how the exception is received in a Web or a Windows client.

# June 28, 2005 9:09 AM

notgartner.com: Mitch Denny's Blog said:

# June 28, 2005 7:03 PM

JosephCooney said:

Here is my coffee-addled oppinion:

Development Time: just throw the exception. Don't do any exception filtering. This will get sent back as a soapfault by the ASMX infrastructure with the exception details included.

Production Time: Return a soap fault. Use an appropriate fault code. Be as generic as you feel inclined to be with the fault detail. A useful analogy might be displaying error information in a ASP.NET application - you say that something has gone wrong, you might give a brief description of the error, but you don't give 'em a stack trace.

Useful resource: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnservice/html/service09172002.asp

# June 29, 2005 6:31 AM

Josh said:

I would vote to definitely throw a soap fault. Do not just let the true exception bubble to the client - they dont need to know the details of your SQL database being down - but don't just return null or an error code. You can handle that by catching specific exception types on your end, logging it, and then throwing a new generic exception/soap fault so the client knows that the operation failed.

I also disagree with the original post stating that class libraries shouldn't let exceptions escape (which makes me think there is a "catch(Exception)" line). Your class library code should only handle exceptions it can definitely do something about - those would be specific conditions (arguments null, invalid format, etc). Any other issues (security exceptions, database issues, etc) should be bubbled up so the consumer can do something about it.

# June 29, 2005 11:04 AM