I'm just looking for some advice on the use case scenarios for creating your own error pages. I've been experimenting with creating error pages and mapping them to codes, and it seems extremely simple to do, yet I've noticed a lot of web sites that don't bother, they simply rely own the browser default. I'm curious as to whether or not there is a standard or set of guidelines for which apporach is best? For such a simple feature, it's extremely underused imho
#Desolate: Best approach is single error page strategy for any kind of exception/error happened at server side with error message: "Some error occurred, please contact customer care at [phone no]/[email] with error code: [error code].
This error code should be searchable in server log files which would give information about timestamp when error happened, user request, user data etc which will help support to investigate.
Related
I inherited an ASP.NET (.NET 4.7.2) application. It has Elastic rigged-up (via the Javascript API) to capture APM data and errors from the front-end.
The top offending errors in Elastic for months now have been:
Uncaught Sys.WebForms.PageRequestManagerTimeoutException: The server request timed out.
Uncaught Sys.WebForms.PageRequestManagerServerErrorException: An unknown error occurred while processing the request on the server. The status code returned from the server was: 404 (but sometimes it will say 503).
Both refer to ScriptResource.axd as being the "culprit".
On the one hand, it sure would be nice if I could find out exactly WHAT resource or URL was being requested... as well as which page in my app is doing the requesting.... when such an error occurs.
But I'm at the point now where... as an alternative, I'd just be happy to change these from being unhandled exceptions to handled ones. (I don't think our users are actually having any serious issues from these. The major page for this app is one that updates a couple of key update panels once every 8 seconds. So, occasional failures of those requests are somewhat expected. Users would have already raised hell if something major was going on.)
I'd much rather see any errors in Elastic that are coming from our own Javascript code than from the Ajax Control Toolkit.
So, does anyone know how I might capture these?
I THINK I've finally found the right information (though some of these pages are from 2008). How to basically add a custom error handler to the Script Manager:
Script Manager 4.5 handling errors
https://social.msdn.microsoft.com/Forums/en-US/59a34e36-f80b-4344-a793-8ea2ce21abe2/ajax-exception-handling?forum=aspdotnetajax
Handle Asynch error messages with ScriptManager
https://blog.digitaltools.com/post/2010/02/03/Unhide-Exceptions-Hidden-By-AJAX.aspx
Looks like I should be able to either bury the exceptions... or get more details on them and pass them on through to get thrown to Elastic.
I think my biggest hurdle right now would be to actually try to recreate these errors myself (preferably in a non-prod environment). But I guess I'll figure that out somehow.
Thanks!
I recently received a feedback from a colleague about my source code of a website. He says that it is a bad practice to not handle gracefully what visual interface does not allow to do.
Since it's not very clear, here's an example.
Let's say a visitor can comment something.
A comment is saved into a database, in a nvarchar(500) column.
The <input /> field length is limited to 500.
But, of course, nothing forbids to a more advanced user to disable the length limit and to type 501 character.
(Other examples: submitting an option which does not even exist in a <select />. But there is a graceful error when the user is asked to enter a number, and she enters a non-number instead, since keypress events are controlled through JavaScript, and JavaScript may be disabled)
If the visitor does so, there would be a failure on code contracts level. The AJAX request would fail with an unexpected error (or, on page submit, there will be an unexpected error). In all cases, the visitor will see that something wrong happened, but will have no graceful message indicating that the length of the submitted comment is too long.
Why is it bad practice? Why would I bother to design clear and explicit error messages for the cases where the visitor who uses correctly the website will never have?
Note: I understand that it sucks to display a .NET Framework detailed error and a stack trace when something like this happens. If I do so, it's a serious security issue. But in my case, there is just an AJAX response with something very generic or a redirect to a generic page with the apologizes about an error.
Since everyone appears to be missing your actual question, I'll put in my 2c (though I'll no doubt be downvoted in retaliation)
As long as your inputs are validated server side (your client-side maxlength is probably ok, though some obscure browsers may not support it), you can return a generic error message as long as it contains no exception information (which you have stated it doesn't).
If, however, it's possible to fail validation via lack of javascript or incorrect entry, then a custom error message should be provided for the sake of the user's sanity.
In short, what you are doing is fine.
First an most importantly
You should validate everything the user supplies on the server! This means not letting 501 letters through
Other than that if an unhandled exception occurs you should show the user a message which gives nothing away. If you were to return exception information this is gold dust to an attacker.
The best method is to display a general error such as "We're sorry, we're working on the problem straight away" and e-mail the exception information to the developers in order for them to fix it.
Why would I bother to design clear and explicit error messages for the cases where the visitor who uses correctly the website will never have?
If everyone used the web correctly, we'd never need to have validation.
As Ronald Reagan once said, "Trust, but verify".
Put in server-side validation for the length of fields. Put in validation to make sure there aren't any XSS or SQL Injection attacks. It's not the people who use your site correctly that you have to worry about, it's the ones that use it maliciously.
I think that the largest part of the problem is that you are assuming that validation should only be happening in the UI. It really is best to validate in the UI and the backend. There is no need to return a stack trace or detailed exception information. On Page_Load(), you should always be validating all user input again and displaying the information statically, as if the user has disabled JavaScript.
What you're describing isn't just bad practice, it's bad design. If you can anticipate an error or exception, then you should anticipate methods of handling it, mitigating it or alleviating it. This goes for any interface design whether it's for a website or a refrigerator. If a visitor gets a generic error and is given no insight as to how to fix it, then why should that person bother using your website? If they're forced to (for work reasons maybe), then all you've done is alienate your customer and give yourself a bad name.
I would suggest you ask yourself why you're not handling these very easy to control situations. Is it laziness or do you just lack experience as a user?
Server side validation is for two main purposes:
as a graceful degradation if the client validation doesn't work for some reason
in this case, you want a nice user-friendly message
as a security measure to ensure malicious clients can't damage your system.
in this case, you want no internal details displayed
If you want to take the route of true graceful degradation, it would be NICE if the server still gave back the user a friendly message for each validation.
In the case of maxLength, this is not very likely to be needed. But many kinds of validation use Javascript, and there are still those people or platforms that don't support Javascript. Older mobile platforms would be the main suspects here.
However, these days, most of us assume that Javascript can be relied on, so a generic error message if server validation fails is fine.
Bit of a long shot but has anyone come across a “Method error 12152” in a cascading dropdown list from the AJAX control toolkit? This is occurring in a system which is used globally but the error is only surfacing in Chinese language clients. There have been no recent codebase or server changes and the error has only just started and is occurring on multiple clients (again, only Chinese clients).
This doesn’t appear to be a server generated error as ASP.NET health monitoring is not picking up any events. A quick Google search only returns a handful of results and they’re predominantly in Chinese so my best guess is that this is a client generated error message possible related to an HTTP timeout but I'd really like a definitive answer on the error code.
I'm not sure you should rule out server errors. This is a symptom of a web service method call failing. I would double check the method in the debugger if you can.
I have a Flex 3 app which I want to instrument to report errors generated by the app to a server via simple HTTPService call.
My idea is to wrap all the methods in try ... catch blocks which then pass the Error object to the reportError() function (which then fires off the HTTP request and pops up a dialog) but is there a better way?
I have implemented a system such as the one you suggest, wrapping all of my methods in try/catch and sending the stack trace to a service that emails me the errors. I created a basic format for the error that logs which method the error occurred in. I noticed that sometimes I end up getting null from the stack traces, so I wanted to log that information for these situations.
It GREATLY improved my application. I tracked down a (large) handful of errors and released a much cleaner build to my users. Now I don't ever get the emails.
The better way IMO is something like this.
I've no idea how good is this particular project (aside from this spooky GPL license), but I don't see why logging in action script should be any different from J2EE, C++, or say Python. Yes, it has some sand box security issues, but I think if this solved, you could log into some centralized log server..
Unfortunately, there really isn't -- errors don't bubble up in such a way as to be trappable at a global level, so the only real way you have to catch errors is to try and catch them all manually. (The community's been pretty vocal in asking for a global exception-handling feature for a while, but it's not there yet.)
In my Project (ASP.NET, VB.NET), sometimes a Server Error is showing.
When this error is shown, Users cannot submit their Applications, so that they have to re-type full details and submit again.
How can I escape from these Server Errors?
I think the reason may be Memory issues. Because if the user try to submit again (after Sign Out->Sign In ) then they can submit. Daily twice or thrice Error is happening.
The word "Server" in the phrase "Server Error" refers to your ASP.NET code. You are the server!
If you are running .NET 2.0 or later, you can look into the Application event log (use the Event Viewer applet) for warnings from "ASP.NET". They will include details of what went wrong.
You need to debug your code to find out what's causing this, but the event logs will give you a starting point.
"Server Error" is just a generic message that indicates the the server code (your code) threw an exception that wasn't handled. It shows the user "server error" instead of a specific message so that no implementation details are exposed to outside users.
In other words, without debugging or looking at a log file or something, all you can tell from "Server Error" is that an Exception of any type was thrown.
Sorry, but the information you provided is not helpful in determining the issue.
I think that you'll need to provide a bit more info to get meaningful solutions.
Do you have server logs?
Can you debug through the app as the error occurs?
Does the error occur at a certain time of day, or after a certain regular action?
Does your app attempt to write to a file that may not be accessible?
is it possible that you are experiencing memory issues?
the list could go on, best to do some more investigation and if a more specific issue comes to light edit your question with the extra detail.
AFTER EDIT:
From the extra detail you've provided I wouldn't jump to memory as an issue, in signing out and back in the user is refreshing their session so everything is reset. If you are not seeing anything in your logs you'll need to look at your exception/error handling.
You just haven't provided enough info yet for us to work out the root issue, let alone suggest a solution. That's what you're seeing from all the answers here thus far. Find the event log info and there should be something there to help you, or at least something more to post here.
Try debugging the error? Server Error can be caused by various reasons.
Check for potential infinite loops.
Check for code in the constructor that might fail (especially for web services).
I think I've had cases like this which led to 'Server Error'. I'm assuming you mean the big red 'Server Error' message?
Save all your files and close your Visual Studio and now right click on Visual studio and run as administrator. It worked for me.