views:

166

answers:

1

Let's say I have a web service which returns a collection of images based on a passed in user. Now I call the web service with a invalid user. The call throws a UnauthorizedAccessException with a message saying the user is not authorized to get the collection.

I want this message to be localized. Where do I localize this message, on the client-side based on a error code? Or do I pass a 'language' parameter to the method in the first place? Do I use HTTP status codes so the client can localize the message?

+2  A: 

Returning error codes is as bad with web services as it is in general, and for the same reason - if you require all callers to check error codes after calling the service, then some callers will fail to do so.

You should throw exceptions in the service. Those exceptions will be turned into SOAP Faults. On the client, these will appear as exceptions (for .NET clients, at least). If you choose to display the Message property of these exceptions, that's up to you. If you choose to display it, then it is also up to you to localize it - on the client.

Consider - otherwise, you have to tell the service the culture of the client, just to the service can send localized text back to the client. It's better to simply keep that information on the client.

John Saunders
Okay, this seems more natural to me as well. I'll base the localization on the ExceptionType. This also keeps my server-side code cleaner.
Robert Massa
Removed reference to my deleted answer. Note that SOAP still returns an FaultCode which the client re-throws as a local exception. Personally, I think that's a pointless mechanism.
Dead account
SOAP Faults include a FaultCode, but it's just to categorize the fault as a Server Fault, Client Fault, etc. It's not an error code. Note that WCF and most Java platforms support fault descriptions in the WSDL. The client receives strongly-typed exceptions, not just "SoapException". It's only ASMX that is backwards.
John Saunders