Some idea i've been playing with lately is to create a server/application/session (dunno which level yet) scoped error stack, where you can throw your error to (next to fysically log it, which i always do), and just have the function return the location of the error on the stack. So you can use the stack in your code later on to retrieve more information then just a true/false, allowing you to execute more conditional logic.
I do the same for queries: the statement, the resultset, a cursor and some other stuff gets stored in a session scoped object, so i'm thinking: why not do the same for errors? Is this a ridiculous idea or is there some value in it? Regards, Stijn Dreezen On Thu, 31 Mar 2005, Roland Collins wrote: > But it would be far more flexible (and useful) to trap the LDAP error and > then re-throw it with your own information appended to it. This lets the > developer that uses your API know what is going wrong instead of just > blindly knowing that it failed. You could do this, for instance (the types > are made up since I'm not sure of their exact definitions): > > <cfcatch type="ConnectionError"> > <cfthrow type="AuthenticationException" message="Unable to connect > to the authentication store." detail="#cfcatch.message#"/> > </cfcatch> > <cfcatch type="AuthenticationError"> > <cfthrow type="AuthenticationException" message="The credentials > supplied were incorrect." detail="#cfcatch.message#"/>/> > </cfcatch> > > This provides far more detail as to what went wrong to the person that has > to use your API. I'd say a Boolean return value just won't cut it in this > case. > > Roland > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Paul > Sent: Thursday, March 31, 2005 12:25 AM > To: [email protected] > Subject: RE: [CFCDev] cfc check > > > <cfcatch type="Any"><!--- do nothing ---></cfcatch> > > > Never _ever_ do that! > > Well I wouldn't normally do it that way, but CFLDAP doesn't return an empty > query like a SQL query would; if the user authentication fails, it just > throws an error. So my calling page receives the same thing it would > receive if the authentication were against a sql database, that being an > empty table... I don't know if that's justification or not though. > > > If you want to get the user's information, I would do that in a separate > method > > I actually already modified it to return a Boolean and was going to ask - > where would my retrieveUser function live? If I have authenticate.cfc, > which I've modified to call cfldap.cfc instead of tying LDAP to my > authentication function, should retrieveUser be a part of authenticate.cfc? > A different component altogether? > > > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email to > [email protected] with the words 'unsubscribe cfcdev' as the subject of the > email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting > (www.cfxhosting.com). > > An archive of the CFCDev list is available at > www.mail-archive.com/[email protected] > > > > > > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email to > [email protected] with the words 'unsubscribe cfcdev' as the subject of the > email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting > (www.cfxhosting.com). > > An archive of the CFCDev list is available at > www.mail-archive.com/[email protected] > > ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
