Ah yes - Web services. Fair call ;o)
Having not played a fair bit with them - I'm suddenly curious about the various ways of handling errors with them. Guess I'll wander off and do some research! ;o) Cheers, Mark -- [EMAIL PROTECTED] ICQ: 3094740 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of gary menzel Sent: Thursday, 23 January 2003 12:50 PM To: CFAussie Mailing List Subject: [cfaussie] Re: CFC and Error Catching Hello Mark, In the case of a Web Service, the executing application is a browser (or some other application sitting) out on a TCP/IP (HTTP) connection to Cold Fusion. �I dont believe there is any standard for marshalling exceptions over the SOAP protocol (which is what the Web Service is using to communicate). So - the only option is to catch your exceptions (however they are generated on the server side) and then provide an appropriate mechanism to either just "keep going" or "tell the caller". If you are calling your CFC's inside the server scope (ie. not via a web service) then you CAN use either CF's error handling template or your own handlers inside TRY/CATCH. BUT..... in doing so you may have troubles if you ever want to then call that as a web-service. Gary Menzel IT Operations Brisbane -+- ABN AMRO Morgans Limited Level 29, 123 Eagle Street BRISBANE QLD 4000 PH: 07 333 44 828 �FX: �07 3834 0828 [EMAIL PROTECTED] wrote on 01/23/2003 11:30:54 AM: > Oh joy - I feel like I'm back in the days (not that long ago really) of > C programming where I had a variety of error codes passed back on every > method.... > > I thought I had got away from those days.. I guess I was wrong :oP > > Stupid question - > > What's wrong with just utilising CF's error handling template? Or is > that more as a 'last resort' in case an exception isn't caught along the > way, and you would prefer to be able to show SOMETHING as opposed to the > default error screen? > > - Just playin' devil's advocate ;o) > > Mark > > -- > [EMAIL PROTECTED] > ICQ: 3094740 > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf Of gary > menzel > Sent: Thursday, 23 January 2003 11:12 AM > To: CFAussie Mailing List > Subject: [cfaussie] Re: CFC and Error Catching > > > > > > > > > I have faced this issue with a Web Service I have developed for an > external > supplier. > > What was done here was to create a structure that was ALWAYS returned - > with an appropriate ErrorCode and ErrorString always embedded into the > Struct. > > If the Struct contains a non-zero ErrorCode, then the ErrorString will > contain a meaningful message that can be displayed to the user (or the > application can process the error code and make up its own appealing > message) and the embedded data (i.e. a QUERY or an ARRAY) just WONT > exist > in the Struct. > > That way you ALWAYS get something back that you can work with and the > caller is responsible for error checking. > > Now..... not that I have used CFTRY/CFCATCH in that particular > web-service > - but it is the same concept. > > So - in short - I dont return the actual data type for the call - I > return > a wrapper struct. > > Gary Menzel > IT Operations Brisbane -+- ABN AMRO Morgans Limited > Level 29, 123 Eagle Street BRISBANE QLD 4000 > PH: 07 333 44 828 �FX: �07 3834 0828 > > [EMAIL PROTECTED] wrote on 01/23/2003 09:50:45 > AM: > > > Heres the latest and greatest issue that leaves me biting my nails > into > the > > wee hours of slumber.. > > > > Like most here I utilise the power of CFC's more so for everything > that I > > have ever done before, and I would like to setup a cftry / error > catching > > system on sensitive method calls cf (i.e. Query Calls, File > Manipulation > > etc). I also like most of you wish to keep all Presentation Layer > Logic > out > > of the cfcs, thus allowing for both browser and flash to not suffer > (or > even > > pda's but that's another email altogether). > > > > Usually in the past prior to CFMX I used to do a try/catch on all > queries, > > in the event the datasource is down etc so that the end-user visiting > the > > site see's a warm fuzzy feeling "oops" page, while alerting me as to > what's > > happening so I can fix it. > > > > Heres the scenario, I need to come up with a solution to allow the > same > > concept to be applied to the cfmx, I have separated my database > interaction > > from the "parent" component.. eg: > > > > products = createObject("component","comp.products"); > > > > products.sql = createObject("component","comp.productsSQL"); > > > > Inside the SQL component I have cftry/catch between the cfcomponent > tags, > > and inside the cfcatch I do my usual logging/email outs etc, but I > also > then > > define a new structure called "compERROR" and inside that I add my own > > custom messages as well as appending the actual error message to this. > > > > One theory we have is that when you make "sensitive" calls from the > caller > > page, you do an if/else statement directly after it to make sure that > you're > > expected returned results are safe i.e.: > > > > <cfscript> > > > > qProductRegions = products.sql.productRegionsSELECT(); > > > > </cfscript> > > > > <cfif isDefined('compERROR')>cflocation to pretty page </cfif> > > > > This basically works, but with as you can imagine some to if not allot > of > > limitations, especially when one assumes that its a direct call from > the > > actual caller page to the query component.. but in many cases the > > presentation layer may not be making the direct call, it may be via a > public > > method which makes calls to private methods? > > > > How would one then trap that error, and halt the overall process then > and > > there, while returning an error safely back to the presentation layer > > without causing errors within errors... i.e. if you have a method > expecting > > a "query" result, and you return nothing, then that cfcomponent will > > generate an error? so it never freakin stops. > > > > > > > > I guess, what's peoples input on error catching and control with > Coldfusion > > Components. > > > > > > > > -- > > Freelance Application Developer / Designer > > -- > > ph: 07 3288 6702 > > mob: 04040 32812 > > -- > > url: http://www.spidaweb.com > > > > > > > > > > --- > > You are currently subscribed to cfaussie as: > [EMAIL PROTECTED] > > To unsubscribe send a blank email to > [EMAIL PROTECTED] > > > > MX Downunder AsiaPac DevCon - http://mxdu.com/ > > > > --- > You are currently subscribed to cfaussie as: [EMAIL PROTECTED] > To unsubscribe send a blank email to > [EMAIL PROTECTED] > > MX Downunder AsiaPac DevCon - http://mxdu.com/ > > > --- > You are currently subscribed to cfaussie as: [EMAIL PROTECTED] > To unsubscribe send a blank email to [EMAIL PROTECTED] > > MX Downunder AsiaPac DevCon - http://mxdu.com/ --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MX Downunder AsiaPac DevCon - http://mxdu.com/ --- You are currently subscribed to cfaussie as: [email protected] To unsubscribe send a blank email to [EMAIL PROTECTED] MX Downunder AsiaPac DevCon - http://mxdu.com/
