Why return a Success boolean from a web service?

KitWest

Jeromy Carriere's MSDN Webcast: Patterns and Anti-Patterns in SOA critiques web services implemented as a Sub (void method), with no indication of success returned. I don't understand why we would want the clutter of in-line checking for success. There's no end to it once you start down this path -- instead, why not catch exceptions thrown by the web method It seems even if you call a method asynchronously, your callback method should catch exceptions and raise them in the usual manner; otherwise, just code for the "happy path" and keep it readable.

Now that we have exception support, shouldn't the 80's style manner of in-line error-checking be discarded

Thanks.

Alexey Raga

I think he wanted to be sure about the result even the web service sor some reason catches the exception on the server side...

In my opinion it depends on situation.. I always use the return value only if I need it in my code.

Udi Dahan The Software Simplist

It's all an issue of encapsulation / contracts. Would you be comfortable getting some strange Oracle/Ms SQL/DB2/some other db unique constraint exception and figuring out that the problem was that there was a duplicate product name Or would you rather get an explicit result that informs you about that case

Generally speaking, the problem with exceptions is that they expose internals.

Alexey Raga

Rignt, but "true/false" result doesn't provide me with any information.
The exception fact itself is equal to "true/false". If I just want to know if the method call was successfull or not I can catch SoapException and be sure that I know it.
But if I change the logic and want to know any details, to know WHY it doesn't work.. I cannot know it with "true/false" result at all.

Well, about the exceptions. There is a good policy: if you expect the exception, catch this type of exception and then throw your own type of exception which will be much more informative for up-level code.

For instance, if my method incapsulates some data manipulations and database calls, it expets database exceptions as well as other kind of exceptions which can occure during data manipulations.

So I will catch all database exceptions and then create my own instance of the exception (something like MyService.DatabaseIsNotOperableException), set the InnerException property and throw my new exception.

The same with data manipulations, (let's say MyService.InvalidDataProvidedException) etc.

So, when I call this (web)method. I will not have "low-level" information such as unique constraints, my app doesn't know anything about any constraints.
But I WILL have the information and I WILL know what happens (database problem, input data is wrong, which data, etc). And I know exactly that my (web) method can throw particulary these exceptions, I can (sometimes) handle the situation in code.

At least I can provide user with the information "what's wrong" instead of just saying "I received false, your request was rejected".

Ollie Riches

IMO a web service is an implementation of the request repsonse pattern, the use of a web service as a one way pattern can be hazardous - connection issues, transportation issues, security & versions issues to say the least.

As for exceptions and web services IMO if the web service is public (internet) then the business logic encapsulated in the web service should not throw an exception from a web service method, it should return a response message that indicates failure with the respect error message that does not give way any critical information - all errors that occur inside the business logic would be logged for later investigation.

The exceptions that occur from calling a web service IMO should only be cause by the soa[ stack not business logic inside the web serivce methods, remember raising an exception that is not neccessary is expensive.

HTH

Ollie Riches

Riekesh

 

I agree. In pevious language, it wat dificut to catch the error within a scope.

Now the requesting application can make his own decission how to handle the error.

 

Except when we are dealing with common services. The error can also reveal security issues