Alternative to CFTRY/CFCATCH
In my environment, we are restricted from using CFTRY/CFCATCH for anything. I am attempting to param the URL attributes for a page. I have listed the code below...can anyone advise an alternative method to this and still get the same result?
<!--- Kill extra output. --->
<cfsilent>
<!--- Param the URL attributes. --->
<cftry>
<cfparam
name="REQUEST.Attributes.date"
type="numeric"
default="#REQUEST.DefaultDate#"
/>
<cfcatch>
<cfset REQUEST.Attributes.date = REQUEST.DefaultDate />
</cfcatch>
</cftry>
<cftry>
<cfparam
name="URL.month"
type="numeric"
default="#Month( REQUEST.Attributes.date )#"
/>
<cfcatch>
<cfset URL.month = Month( REQUEST.Attributes.date ) />
</cfcatch>
</cftry>
<cftry>
<cfparam
name="URL.year"
type="numeric"
default="#Year( REQUEST.Attributes.date )#"
/>
<cfcatch>
<cfset URL.year = Year( REQUEST.Attributes.date ) />
</cfcatch>
</cftry>
<!--- Based on the month and year, let's get the first
day of this month. In case the year or
month are not valid, put this in a try / catch.
--->
<cftry>
<cfset dtThisMonth = CreateDate(
URL.year,
URL.month,
1
) />
<cfcatch>
<!--- If there was an error, just default the month
view to be the current month. --->
<cfset dtThisMonth = CreateDate(
Year( Now() ),
Month( Now() ),
1
) />
</cfcatch>
</cftry>
</cfsilent>
I'm pretty sure you could re-write it and simplify to achieve something similar. But as far as cftry/cfcatch ....
> That makes no sense
+1. There is no reasonable alternative to a try / catch. The best you could do is try and handle most possibilities with a ridiculous series of cfif's:
<cfif not structKeyExists(request.at
not IsNumeric(request.attribut
<cfset request.attributes.date = REQUEST.DefaultDate>
</cfif>
<cfif not structKeyExists(URL, "month") or
not IsNumeric(URL.month)>
<cfset URL.month = Month( REQUEST.Attributes.date )>
</cfif>
.... etc....
But ultimately, if you missed anything your page will just blow up without the try/catch. The <cfsilent> won't prevent that afaik. There's just no substitute for try/catch.
> That makes no sense
+1. There is no reasonable alternative to a try / catch. The best you could do is try and handle most possibilities with a ridiculous series of cfif's:
<cfif not structKeyExists(request.at
not IsNumeric(request.attribut
<cfset request.attributes.date = REQUEST.DefaultDate>
</cfif>
<cfif not structKeyExists(URL, "month") or
not IsNumeric(URL.month)>
<cfset URL.month = Month( REQUEST.Attributes.date )>
</cfif>
.... etc....
But ultimately, if you missed anything your page will just blow up without the try/catch. The <cfsilent> won't prevent that afaik. There's just no substitute for try/catch.
ASKER
I will have to look at the specific reasons but it's just the challenge I'm presented with. I will try what you suggested agx...thanks!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Looking at the code, it seems to me that you want the value of
REQUEST.Attributes.date
and
URL.month
and
URL.year
to all be in sync? Don't you?
For example, if the date is 10/1/2011, but on the URL the month passed is 9 and the year is 2009, do you really want a date that doesn't match the month and year? Or is this an overly cautious way to just get tha date and find the month and year?
REQUEST.Attributes.date
and
URL.month
and
URL.year
to all be in sync? Don't you?
For example, if the date is 10/1/2011, but on the URL the month passed is 9 and the year is 2009, do you really want a date that doesn't match the month and year? Or is this an overly cautious way to just get tha date and find the month and year?
Ok, I certainly admin that this code snipped doesn't match the logic of the askers code 100%, but I am really wondering if leer's logic is what he wants?
The following logic is: if the month and year passed in on the URL can make a valid date, then use it, otherwise, use the first day of the month found in request.attributes.date, if that is not a valid date, then use the first day of the current month.
leer, if that's not it, can you tell us your desired algorithm?
The following logic is: if the month and year passed in on the URL can make a valid date, then use it, otherwise, use the first day of the month found in request.attributes.date, if that is not a valid date, then use the first day of the current month.
leer, if that's not it, can you tell us your desired algorithm?
<cfparam name="url.month" default="">
<cfparam name="url.year" default="">
<cfset dtThisMonth = url.month & "/1/" & url.year>
<cfif NOT isDate(dtThisMonth)>
<cfset dtThisMonth = Month(REQUEST.Attributes.date) & "/1/" & Year(REQUEST.Attributes.date)>
</cfif>
<cfif NOT isDate(dtThisMonth)>
<cfset dtThisMonth = createDate(Year(Now()),Month(Now()),1)>
</cfif>ASKER
Server administrator reasoning:
Using CTRY/CFCATCH/CFTHROW/CFRET
Using CTRY/CFCATCH/CFTHROW/CFRET
> Ok, I certainly admin that this code snipped doesn't match the
Lol, can anyone decipher this?
"Ok, I certainly admit that this code snippet doesn't match..."
Lol, can anyone decipher this?
"Ok, I certainly admit that this code snippet doesn't match..."
ASKER
It's a numeric way of gathering the date. The calendar displays defaulting to the current month and highlights the current day. There are links to go back to the last month or go forward to the next month. If I clicked the link for September 2011 (which would be last month), the url would look something like this:
calendar_index.cfm?viewas=
If I clicked the link for November 2011 (which would be next month), the url would look like this:
calendar_index.cfm?viewas=
You can also see a week view, so if i click for the current week, the url would be:
calendar_index.cfm?viewas=
And if I wanted to view just the day, the url would be:
calendar_index.cfm?viewas=
With what agx suggested, it works for the month...I'm just coding my week and day pages to replace those CFTRY/CFCATCH.
calendar_index.cfm?viewas=
If I clicked the link for November 2011 (which would be next month), the url would look like this:
calendar_index.cfm?viewas=
You can also see a week view, so if i click for the current week, the url would be:
calendar_index.cfm?viewas=
And if I wanted to view just the day, the url would be:
calendar_index.cfm?viewas=
With what agx suggested, it works for the month...I'm just coding my week and day pages to replace those CFTRY/CFCATCH.
hmmm, I don't see how those examples correlate to the code. The URL is always showing "date" not "month" and "year" also, you never mentioned Request.attributes.date, where does that come into play?
I just think the code is doing more work than it needs to with all those catches anyway...
I just think the code is doing more work than it needs to with all those catches anyway...
> however, it also hides errors from the ColdFusion Application log.
Wow, that's is scary.
I use cfthrow as part of my regular validation code to trap invalid entries. Do they want "Last Name is Required" to be logged?
So, rather than handling any problem at the page level, they are forcing you show a "Failure" page and send the user out of their area all together. So, if there is a bug in one small aspect (say go-back-one-year), instead of showing the user a friendly message that "the system is not alble to satisfy their request at this time" -and allow them to continue work, you have to throw them out of the app...
I think you should post who is hosting company is so it can be avoided...
Wow, that's is scary.
I use cfthrow as part of my regular validation code to trap invalid entries. Do they want "Last Name is Required" to be logged?
So, rather than handling any problem at the page level, they are forcing you show a "Failure" page and send the user out of their area all together. So, if there is a bug in one small aspect (say go-back-one-year), instead of showing the user a friendly message that "the system is not alble to satisfy their request at this time" -and allow them to continue work, you have to throw them out of the app...
I think you should post who is hosting company is so it can be avoided...
"Using CTRY/CFCATCH/CFTHROW/CFRET
Yes errors don't show up in the log when you use CFcatch - because they -aren't errors- at that point. they are properly handled code execution
if your admins want to see log entries it's as simple as adding
cfcatch>
<cfset URL.year = Year( REQUEST.Attributes.date ) />
<cflog file="myAppErrors" value="This is the proper way to handle runtime errors: #cfcatch.type# - #cfcatch.message# - #cfcatch.detail#">
</cfcatch>
Yes errors don't show up in the log when you use CFcatch - because they -aren't errors- at that point. they are properly handled code execution
if your admins want to see log entries it's as simple as adding
cfcatch>
<cfset URL.year = Year( REQUEST.Attributes.date ) />
<cflog file="myAppErrors" value="This is the proper way to handle runtime errors: #cfcatch.type# - #cfcatch.message# - #cfcatch.detail#">
</cfcatch>
"server administrators have NO means of determining where a problem may lie."
maybe server administrators need to do a little refresher course cause frankly they are just plain wrong here. And you can quote me on that too ;)
maybe server administrators need to do a little refresher course cause frankly they are just plain wrong here. And you can quote me on that too ;)
oops not value sb text
<cflog file="myAppErrors" TEXT="This.....
<cflog file="myAppErrors" TEXT="This.....
ASKER
Hey SidFishes...can't use CFLOG either. Hahahahahahaha.
ASKER
I just deal with it and work around it.
ASKER
In any case...it all works now.
can't use cfcatch cause errors aren't logged and can't use cflog - just nuts.
GD, agx maybe can we start an online petition so leerljr68 can use these basic tools and quit wasting time trying to work around unreasonable & silly restrictions.
yeesh
GD, agx maybe can we start an online petition so leerljr68 can use these basic tools and quit wasting time trying to work around unreasonable & silly restrictions.
yeesh
I know that doesn't answer your question (and frankly I don't think there -is- an alternative) but sometimes pointless restrictions need to be challenged (and you can quote me on that ;)