I don't know, it's the same for XSLT right? You probably WANT to know that there's an error else you'll be puzzled as to why content is not showing up.
Just prevent the errors from being able to happen in the first place! ;-)
But that did just give me a thought, as a hack, you can probably find all elements that have an attribute: style="border: 1px solid #990000;" and hide set display to none.
Not up to me though, do create the report in Codeplex and let the team decide.
so that it be always possible just to hide this div from an end-user with simply adding a rule to the css.
Currently the string <div style="border: 1px solid #990000"> is just hardcoded in the sources and there's no way to change it without source code modification.
Personally, I am against hiding errors, you will never know the error exists and if it's in the main menu for example it could take weeks for some site visitor to complain that there's not much content on the site. While, if there's a real and ugly error on the site, people are more likely to contact you about it.
And, even if I was joking above.. you should make sure no errors show up in the first place by creating you macro to be robust. Again, it's much nicer to find these problems early so you can solve them ASAP instead of getting that annoying call weeks later: "This hasn't worked for WEEKS, WTF!?".
I agree with Seb. Hiding errors is the equivalent of an empty Catch block which is considered bad practice. Solve the underlying problem, don't try and cover up the symptons!
The only things I find annoying is that errors in macros are cached like any other content. I've reported this as an issue in Codeplex - please feel free to vote it up :)
Switch razor error and red box off
Hi
I would like to switch the razor error reporting off from a website how do you go about doing this?
Cheers
Jon
Unfortunately, this is the only way:
@{
try {
Razor stuff
}
catch() { }
}
Bummer :(
Should I add this feature to the tracker?
I don't know, it's the same for XSLT right? You probably WANT to know that there's an error else you'll be puzzled as to why content is not showing up.
On a production site I would prefer the error to be put in comment tag not in a bright red box with a stupid error no user will ever understand! ;)
Just prevent the errors from being able to happen in the first place! ;-)
But that did just give me a thought, as a hack, you can probably find all elements that have an attribute: style="border: 1px solid #990000;" and hide set display to none.
Not up to me though, do create the report in Codeplex and let the team decide.
As a suggestion, may be it could be a good thing just to have some CSS class attached to a generated error div automatically like:
<div style="border: 1px solid #990000" class="umbraco-razor-error">
so that it be always possible just to hide this div from an end-user with simply adding a rule to the css.
Currently the string <div style="border: 1px solid #990000"> is just hardcoded in the sources and there's no way to change it without source code modification.
Yeah my sugestion would be to have a class on the error so at least i can choose to display it or not :)
I do like the ide of stopping them happening but sometime it's not that easy.
Personally, I am against hiding errors, you will never know the error exists and if it's in the main menu for example it could take weeks for some site visitor to complain that there's not much content on the site. While, if there's a real and ugly error on the site, people are more likely to contact you about it.
And, even if I was joking above.. you should make sure no errors show up in the first place by creating you macro to be robust. Again, it's much nicer to find these problems early so you can solve them ASAP instead of getting that annoying call weeks later: "This hasn't worked for WEEKS, WTF!?".
I agree with Seb. Hiding errors is the equivalent of an empty Catch block which is considered bad practice. Solve the underlying problem, don't try and cover up the symptons!
The only things I find annoying is that errors in macros are cached like any other content. I've reported this as an issue in Codeplex - please feel free to vote it up :)
is working on a reply...