> When it blows inside of /Application.cfm, which isn't subject to
> try/catch. I try to but up a backup cferror statement inside of that
> file as high up as possible for just that reason.
My bad...it is crashing inside Application.cfm...so it's off to implement a
CFERROR solution
Thanks Matt
On Apr 7, 2005 10:48 AM, Bryan Stevenson <[EMAIL PROTECTED]> wrote:
> Thanks Matt ;-)
No problem, and you were right that something was off in that
try/catch thing I was talking about. I was going off hazy memory.
What you can't do is put your try in /Application.cfm and your catch
in OnRequestE
Hey Matt...it does work..and it's already in production ;-)
Thanks
Bryan Stevenson B.Comm.
VP & Director of E-Commerce Development
Electric Edge Systems Group Inc.
phone: 250.480.0642
fax: 250.480.1264
cell: 250.920.8830
e-mail: [EMAIL PROTECTED]
web: www.electricedgesystems.com
On Apr 7, 2005 2:37 PM, Matt Robertson <[EMAIL PROTECTED]> wrote:
> What you can't do is put your try in /Application.cfm and your catch
> in OnRequestEnd.cfm. Thinking on it I can't see a reason why
> /Application.cfm can't have its own try/catch, unless there's a cf
> rule somewhere that says so
I've been playing around with this and I see a problem can't solve. I
can force a raw CF error to screen, regardless of whether you have
try/catch, a site-wide error handler or cferror (or all three).
I start out with this /Application.cfm
#haha.notexists#
which has a query loop to a nonexis
Correct me if I misunderstood what you are getting with your last example
but from what I can tell the explanation below seems reasonable to me
Because your last example doesn't even get compiled due to the closing >
being missing on the cfoutput, CF doesn't see any code that you have in that
and it's very unlikely (even with minor testing) that a malformed tag
would make it into production ;-)
I think Paul's answer is a good one for all to remember..CF can only do so
much...and it sure can't read your mind and extrapolate what the rest of the
code in the file should be...hehe
I've got part of the answer. Its a bug in ColdFusion. In the
previous example I created an error just in front of the CFCATCH
statement, so the value of error.message is
Invalid token 'c' found on line 6 at column 2.
Line 8 is and is the highlighted line on the raw
CF error message.
If instea
Paul,
What I was getting at is not that the template wasn't doing its catch
thing due to malformed CF. I understand why that won't compile. The
issue I found is that I can also cause the sidte-wide error handler to
break as well, but break in an odd way that exposes a raw CF error
message AFTER
Are you declaring your site wide error handlers in the application file or
are you declaring them in the CFADMIN area?
The thing with the errors that you are creating is that the two mods to the
code you made will have very different results and I don't think the error
handlers that are declared i
I am setting up the site-wide error handler in the CF Administrator.
Its called whammo.cfm and its code is displayed in my original post on
this.
Then there's the try/catch error handler. Thats oops.cfm and its
declared at the bottom of /Application.cfm. It has the same code as
whammo.cfm only
Ok,
I follow all that... I'll see if I can re-create it here...
Paul
~|
Logware (www.logware.us): a new and convenient web-based time tracking
application. Start tracking and documenting hours spent on a project or with a
cli
And if you can create a relatively self-contained reproducible test
case with instructions, send it to me and I'll test it on various CF
versions and if it's still broken in CF7, I'll file a bug!
On Apr 7, 2005 5:05 PM, Paul Vernon <[EMAIL PROTECTED]> wrote:
> I follow all that... I'll see if I ca
Here's a gif of what it looks like on my dev server
http://foohbar.com/kaboom/errorscreen.gif
And to stir the pot further, Its NOT doing it on my live server. I
uploaded the same bad code to a live web site and my own site-wide
error handler works fine. It may be that the for-real error handler
OK its very simple code. I'll send it over. Mostly what I posted
already. But it doesn't happen on my live server. Only my dev box
here on my desktop, where I could put in a simple s/w error handler on
a relatively clean system. The live box is probably better patched
than this desktop.
--
-
ler code.
I've tested this in MX 6.1 fully patched and MX 7.
Paul
-Original Message-
From: Matt Robertson [mailto:[EMAIL PROTECTED]
Sent: Friday, 08 April 2005 01:17
To: CF-Talk
Subject: Re: SOLVED: Re: CFTRY/CFCATCH exposing CF errors?
Here's a gif of what it looks like on m
Your first example is correct cfcode. Maybe a typo when you wrote the
msg? Should be
#cgi.http_user_agent#http://www.houseoffusion.com/banners/view.cfm?bannerid=67
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:201965
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4
Subsc
Sorry, my typo in the mail... I did try both combinations of incorrect code
and didn't see a raw dump of an error.
My CF version is reported as 6,1,0,hf56580_611 which is I believe as of now,
a fully patched box. This is the dev box and it gets everything that
production gets at least a week befor
On Apr 7, 2005 5:42 PM, Matt Robertson <[EMAIL PROTECTED]> wrote:
> OK its very simple code. I'll send it over. Mostly what I posted
> already. But it doesn't happen on my live server. Only my dev box
> here on my desktop, where I could put in a simple s/w error handler on
> a relatively clean
Thanks again for taking the time to look this over, Sean!
--
--mattRobertson--
Janitor, MSB Web Systems
mysecretbase.com
~|
Logware (www.logware.us): a new and convenient web-based time tracking
application. Start tracking and
20 matches
Mail list logo
