>- see footer for list info -<
Good call, and I think I have an answer for Lee. 

First, as for the error message text, I think it was the lack of normal 
coloring we'd see (he showed only text) which threw me off. I'd just never read 
the text of a standard error page closely, since that phrase would be in dark 
blue (just confirmed). All I'd normally notice was the error itself. :-)

And I want to retract some of what I said in the last note. If the problem was 
that there was no suitable type in the CFCATCH, then CF would just pass the 
error up to any outer error handler, then dump on the screen as traditionally 
(and as we see here). So I would think this means that there was in fact no 
error in his code above the test line. (I mistakenly had in mind that it would 
go into the try/catch but if there was no suitable type, it would be "handled 
and do nothing".)

But I do still stand by point out, Lee, that you may want to stop the request 
when you catch the error.

In fact, I'll make another proposal, and I think this is the answer: I wonder 
if that try/catch WAS fired, but then since you didn't stop, it proceeded to 
the lines that failed (whether this test code, or your original code referring 
to the recordcount), but because that then got another error, YOU ARE NEVER 
EVEN SEEING THE OUTPUT FROM THE ERROR HANDLER, because when the next error 
bubbles up to the traditional error page, CF flushes the output of whatever was 
to be generated on the page.

Lee, put in a CFABORT at the bottom of the CFCATCH (inside it), and see if you 
now see your "handled" error being shown. (You should still add a type="any", 
for any other errors you get, I'd think.) You could also just comment out the 
CFTRY and CFCATCH to see what error happens, but really, you want to be 
aborting processing after doing the catch in this case, I think (again, you 
don't always want to, so it's something you have to choose to do.)

BTW, it's always possible you could have an error in your CFCATCH code itself, 
in which case you'd instead see just the "traditional" error message but 
referring to whatever line really was in error, so be aware of that. 

/charlie


> -----Original Message-----
> From: [email protected] [mailto:dev-
> [email protected]] On Behalf Of Kev McCabe
> Sent: Friday, August 27, 2010 1:40 PM
> To: CFML Development
> Subject: Re: Re: RE: Re: [CF-Dev] Weird Database connectivity issue
> 
> >- see footer for list info -<
> Charlie,
> 
> IIRC "The following information is meant for the website developer for
> debugging purposes" Is Standard CF Error Message. (I guess it's been a while
> both of us have seen one with all the custom error messages we build in our
> systems ;) )
> 
> If the variable RES_APPM8_GET_CLIENT_DETAILS isn't set from the SP I would
> set it to start with, with a cfset RES_APPM8_GET_CLIENT_DETAILS =
> queryNew('') but I have a feeling that the SP will overwrite this with
> whatever comes out the SP, which may of been changed? What is the DB MySql /
> MSSQL?
> 
> ----------------------------------------------------------------------
> [ ] internal   [ ] private   [X] ask first   [ ] bloggable
> ----------------------------------------------------------------------
> Kev McCabe



_______________________________________________

For details on ALL mailing lists and for joining or leaving lists, go to 
http://list.cfdeveloper.co.uk/mailman/listinfo

--
CFDeveloper Sponsors:-
>- cfdeveloper Hosting provided by www.cfmxhosting.co.uk -<
>- Lists hosted by www.Gradwell.com -<
>- CFdeveloper is run by Russ Michaels, feel free to volunteer your help -<

Reply via email to