This is personal opinion, but if you've got a development team that wants to consume your web services, but doesn't have the competence to learn how to interpret a SOAP Fault, I say screw 'em.
There is a standard mechanism for indicating errors with web services, and it's faults. It's not like the developers who don't understand faults are going to be any more gung-ho to learn a custom reporting mechanism, especially if there are a bunch of ways to package the same thing (as an array, a struct, a query, etc). Creating a "custom" mechanism for indicating errors is only going to piss off the people who know what they're doing, and expect to get a Fault message back if there is a problem. My $0.02. Cheers, barneyb > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Milligan > Sent: Thursday, June 03, 2004 3:55 PM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] Catching Argument Type Errors > > > > >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 ---------------------------------------------------------- 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]
