> >Bryan, > >I think you're missing David's point. You *cannot* display a >friendly error message to the person consuming your >webservice, not because you shouldn't but because webservices >are not displayed. XML changes hands, and in the end your >"friendly" error messages are the same sort of SOAP response >as a native SOAP error message--they are both XML to be parsed >and dealt with by the consumer. >
Conversely, I think that David is also missing Bryan's point. If the consumers of a webservice can't understand the errors they're getting back they may well go off and use someone else's webservice instead. That's why I think it makes sense to want to control what's being sent back to the consumer. A consumer in this case is the developer trying to write code to interact with the webservice. >If the consumer is running CF, they will see their own CF >error message. Only after they've decoded the error that's coming back from the webservice and decided how to handle it. It's during that decoding step that you might need something more friendly than what CFMX produces. >If .NET, they will see the .NET error message that they coded. Again, only once they've figured out what the message returned by the webservice means. >If a newsreader, Sherlock, Big Bob's SOAP-O-Matic--they will >see the error message native to those programs. Only if those programs have no logic to interperet an error message. For the most part I would be very suprised if the jist of the error message wasn't passed through in some form to the end user in the 3 examples you gave. > >If the person coding the consuming program wants to see >something more friendly, then they need to code it or give you >access to their program--nothing your SOAP response can >contain will inherently display anything, much less something friendly. They can't code anything friendly if they don't understand the message the webservice is returning. That's the whole point. > >Your other concerns, such as logging the error on your end, >seem to be a valid reason to pursue this sort of control, but >friendly error messages are impossible no matter how you code them. > That depends on what you mean by 'friendly error messages' If you mean nice warm fuzzy messages that an end user will understand then I agree with you, but if you mean useful informational messages that a developer attempting to use your webservice can understand then I strongly disagree. Spike -------------------------------------------- Stephen Milligan Code poet for hire http://www.spike.org.uk Do you cfeclipse? http://cfeclipse.tigris.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
