http://coldfusion.com logo
Join Slack
Powered by
question to everyone....in application.cfc file, t...
# cfml-general
f
question to everyone....in application.cfc file, there is a global error handler....if that is setup and has a file in there, should it catch ALL errors that are not trapped locally with say try/catch, OR are there any errors that the global error can't catch? right now one of my team members says he had to or we have to put try catch around ALL functions, so we have to fix over 1000 functions.....any thoughts?????
z
I'd say code always speaks louder than words, ask them to demonstrate their theory!
👍 2
f
@zackster yeah we are having a meeting to do that, but i wanted to check with the community to see....i thought in general just put error.cfm file in onError and that should catch stuff not caught locally where error is
z
that's the theory, there are potentially buggy edge cases, oh to be a fly on the wall at that meeting!
like errors in error handlers, triggering the error handler, they are always fun to debug
👆🏻 1
f
looks like our code might not have a cfm file in the onerror just calling a function to handle the error....hmmm
z
sounds possibly more like a potential code quality issue, maybe advocate improving the code rather than just wrapping everything in try catch, are you using something like sentry?
f
not sure what sentry is plus probably not something government will like...main thing is we can't have the CF error show in the browser showing things like ip and others....should just show an error page...
z
sentry is great, you send all your error there and you can track them, you're using ACF or Lucee? https://sentry.io/product/error-monitoring/
n
Re hiding the errors from public - isn't there a generic error template you can use? i.e set in CF admin / lucee admin
z
yeah and the onError handler, sounds like you have it all covered already?
f
ok, i see....i think we are just putting the errors into an error log, but we are not doing anything to prevent CF Errors message to show on the screen...as NEOKoening says, general error template....i have to check if we are setting that in CFadmin....but we are not doing anything good in onError
n
Ah just set it in CFAdmin so in production it just means any error will get replaced with that template.
z
as the carpenters say, measure twice, cut once!
👍 1
n
Won't stop cfdump outputs though
z
in lucee you can do 
this.tags.dump.enable=false
for prod
👍 1
f
right on prod we don't need dumps and stuff...but on lower env we should do that....by the way we are on CF2021
z
you know the rules, if you have the template and onError handling set, then if it fails, it's @Mark Takata (Adobe)’s fault
🤣 1
f
OK, sounds like I am not crazy and there is a way to do it in CFadmin, i see on our test server there is no file in the site wide error handler section, and also onError usually you put a message or a cfinclude file to show a generic message....
👍 1
d
Always beware errors in your error handling code. It can be tricky to figure out what actually happened at that point.
Are you using IIS? It has a related setting too.
z
it's good to have your test server show errors tho, unless it's internet facing
👍 1
f
agree, but if we are also storing that info in a log table, we have it tracked, then on prod don't show the CFerror....as for test server yes it is good to show it...i am going ot try to check our prod server to see if they put anything in cf admin
p
Your code should always be compartmentalized in the sense of handling its operation. So each component or function should be handling all of its actions…including error handling but it can extend from another easily to help keep common stuff centralized… And yes you should not display errors publically, which in a dev vs prod mode would work great showing only in prod an error page. And last, yes implement Sentry its super simple and a great tool to analyze reoccurring issues so you can organize your bug fix lists.
n
One of the main reasons to use Sentry is notifications - I like to get an email, but if you have CF send you an email on every error, that means you can mailbomb yourself pretty sharpish on a high traffic site. Sentry is good at sending one for the first instance of an error, and then consolidating / marking as escalating, but not spamming you too much (usually whilst you're swearing and trying to fix the error).
f
I get all the email message, but we need to get global error handler working in cfadmin....when we put in a file path to a error.cfm, it says file is not there.... /temp/error.cfm for example
p
Sounds like a mapping error, do you have any mapped paths for your app in application.cfc?
f
not sure....our webroot is inetpub/wwwroot
so i put the file in wwwroot/temp/globalErrorHandler.cfm but in cfadmin it says it can't find that....
b
We have a function call in the onError function within application.cfc that will dump error info to the screen when in the dev environment and display "Something Went Wrong..." and log the error in a database for Test, Staging and Prod. The errors are then processed every 2 min by a scheduled task which sends an email with links to the applications that are throwing errors, but the errors themselves are not displayed in the email.
f
thanks Brian....i just got a cfinclude file to work in our onError....there was crap code in there that was messing with the function...when I cleaned it out that worked....still not sure why cfadmin not working
👏 1
z
Logging errors to your database ain't great when you get DDOSed
f
i get it...my problem is about cfadmin not able to enter the general error page path....
b
Emailing the errors ain't so great either. We also have a scheduled task that purges all errors more than two weeks (or whatever timeframe we choose) old that aren't saved for follow up.
f
OK all, how we are handling the errors via email or in database was not my reason for posting, it was why can't i add into cfadmin a general error file....
r
Are you having a problem adding a site-wide error handler or the onError() method in the Application.cfc? Your original post implies the later while your last post implies the former.
f
@Rodney lol, this got off the rails....right now site-wide error handler...figure out we had a lot of junk code in onError that messed it up....but can't put a file name into site-wide text field....always says can't find file
r
I believe that needs to go in the webroot of your CF context, not your website. C:\ColdFusion\cfusion\wwwroot by default on an ACF Windows install. It's been a while since I've used that though so I could be wrong.
☝️ 1
It's really a server instance error handler.
f
hey, i'll chekc into that....
z
Or make a mapping?
f
when you say a mapping....mapping from where,?
crap, just putting that file in the c:coldfusoin/cfusion/wwwroot, worked....
👍🏻 1
hmmm, so put that file ino the c:/coldfusion/cfusion/wwwroot folder, and now the error i have on the page, does not show, but it does not read the simple text on the error.cfm file....hmmmm, so it saved in cfadmin, but something is still a bit off....but i am close i guess
r
There are limitations since it is instance wide and outside the scope of the application (I think it still gets the context from the error though). It will not display anything if there is an error in it.
f
thanks Rodney....interesting...it has been so long since I had to set this stuff up...usually this stuff is already set up when i get to my jobs....
Also, if I set this up as a global, then put a cfinclude in the onError, we cover the pretty much all errors....
r
Yes. local try/catch falls back to Application.cfc onError(), which then falls back to the side-wide error handler template.
f
yep....one of my coworkers was going to add try/catch in every function we have in the sit....a crap ton because we did not have the site-wide or onError working right....
😱 1
b
I would be very cautious of any code base which used try/catch in every function. That sounds absolutely terrible, lol
💯 3
My rule of thumb is only catch an error in a "local" sense for two reasons • The error is generic low-level coming from some underlying library (like IOException) and you want to re-throw it with more information about what was happening at a higher level when the error was encountered (i.e. "_Error while writing file for product ID 17 in the folder XYZ..._" ) CF makes this a total pain due to its inability to "wrap" exceptions in a cause. BoxLang has improved this and Lucee to an extent • The error is something which can be recovered from and the page can still be successfully rendered. i.e. auth server 1 didn't respond, so try server 2 before giving up, etc. If the error represents the end of the request and the user will simply get an error response, then there is no utility in trying to catch it at a lower level. At best, it will just obfuscate the source, making it rather hard to track down. Just let your global handling kick in, whether it's in the framework or the application.cfc onError, or the default error tempate set in the admin.
f
@bdw429s totally agree....fix things from top down first, then use try/catch if for some reason the high level error handling does not catch it....don't star at the bottom....
b
> if for some reason the high level error handling does not catch it There are no "uncatchable" errors, at least in this case, so that's not really the reason 🙂
👍 1
z
As I said at the start, I'd love to see the exception which started this whole thread!
f
i think what started this was when i put in a file name into site-wide error, it gave an error stating can't find file...so file was not in the right location
Open in Slack
PreviousNext
Powered by