Failing to catch ASP.Net Server error in sharepoint - javascript

I have an asp.net control that contains a grid view sitting on top of an Ajax update panel. The control has been added to a sharepoint page. When a button is clicked, some server code is called to store the contents of the grid.
If the server code throws an error, I want to spit out a javascript alert displaying the error message, but for some reason the error that bubbles up from the server is the generic 500 server error, which doesn't contain any details of the original error.
Can anyone explain why this is?
Many thanks
Gerry

The default behaviour of ASP.NET (and SharePoint) is to display a generic error page when an exception is thrown. For security reasons, this page hides all details of the error. With debug settings in web.config you can get a stack trace, but that won't give you something easily manipulated in javascript.
To return a custom error page you can either set up a global unhandled exception handler (probably overkill for this) or you can catch the exception and modify the response appropriately. For a rest method you would clear the response, set status to 500 and write the error message to the response. For an UpdatePanel, you would render the panel as an error message or with script to show the alert. Not sure if you would set status in this case - UpdatePanel is an ugly hack to fake true ajax in webforms, so you can't expect the code to be particularly clean.

Related

Collecting javascript errors from users

Some of our customers are reporting that they are unable to execute some javascript actions. Our error data collecting is on the server and when javascript breaks we are unable to get notified it since ajax calls can't be run before page refresh.
Is there a way to collect javascript errors on client side and send them to the server as soon as javascript is running fine again.
Example:
User goes to page a.php.
There's faulty javascript on a.php and it breaks user's javascript.
User's client logs the errors and stores it locally.
User goes to page b.php.
There are no faulty javascript on b.php and the client detects that there's javascript error logs stored locally and proceeds to send them to the server.
The server writes the log up.
There is no need to refresh the page to make AJAX calls. You just need to make sure that the error handling code is in its own script tag so that it won't break if there is a syntax error in the other code.
Here is part of the code that we are using to catch script errors and send them to the server (The AJAX code is in a separate method, but I trust that you already know how to do that):
window.onerror = function (message, url, line, column) {
Ajax.logError(message, url, line, column);
$('body').append($('<div>').addClass('ErrorPanel').text('An error occured in the browser.').delay(5000).animate({ height: 0 }, 2000, function() { $(this).remove(); }));
return false;
};
Maybe you should take a look at New Relic. New Relic is a monitoring tool for software analysis and it's able to show you various information about JavaScript errors (and much more):
http://newrelic.com/browser-monitoring

How do you handle errors for Facebook SDK functions like FB.getLoginStatus()?

Under certain circumstances, using functions like FB.getLoginStatus() will cause console errors such as:
Given URL is not allowed by the Application configuration.: One or more of the given...
The problem is that if an error like this occurs, the callback to the function never gets called. Is there any way to handle errors of this kind? try/catch doesn't work, and the function doesn't return anything directly. I also want to avoid a timeout hack if possible.
There is nothing in the docs explaining how to deal with errors of this kind either:
https://developers.facebook.com/docs/reference/javascript/FB.getLoginStatus
Note: I am not trying to solve the error above, I am trying to figure out to handle it
That error only happens if your App is not configured correctly, so you don´t need to handle it in your code, you just need to make sure to add a platform with the correct URL in the App settings (Website, Page Tab, Canvas App, ...).
Everything else can be handled in the callback response, you don´t need any specific error handling for that, just the code from the Facebook docs. If the settings are correct, there WILL be a response. Meaning: error handling can be done by checking the content of "response".

Is there any global javascript error handler? (even is it possible with just chrome or Firefox)

Javascript applications are growing day by day and getting complex too.
so is there possible to handle uncatched error that occured in app so they can be send back to server for further analysis.
i just see in phpmyadmin app sometimes show a little popup in bottom say that javascript error occurred would you like to send to server.
I am not asking about try catch or block level error handling instead i want to know weather is it possible to handle global errors just like any browser show in console/log areas. if yes then how.
Ohh sorry.. got answers
Logging Clientside JavaScript Errors on Server
The HTML onerror event may be what you want.

Best practice for reporting client errors with window.onerror?

I'd like to catch all client-side JavaScript errors on our site and log them. What are some best practices for doing this?
Thoughts:
I can easily add a /log/ handler to our webapp, parse GET/POST parameters and use our existing logging system on the server-side. Is that too obvious?
Does window.onerror work everywhere? What if an error occurs in the handler?
Should I attach an <img> tag to the page or make an XmlHttpRequest? What if the XHR fails?
What about broken images and jQuery Ajax failures — can I catch those too?
All suggestions made by Jbecwar and dgvid are cool, I would add:
note that Opera does not support error event see quirksmode error event
gathering stacktraces with stacktrace.js could help troubleshoot errors
if error handler is unable to send error report to server side, fallback to using cookies: set cookie for errors.yourdomain.com with base64 encoded error report (compressed?) and request empty 1x1 pixel image from that domain on every page
or use HTML5 local storage and upload it when you can
As Jbecwar suggests, the log handler is a good idea, but you need to watch out for a condition in which you try to call the log handler to report an error contacting the log handler. If the browser loses its connection to the server, you aren't going to be able to log that back to the server.
You can catch an img load failure by attaching an error handler to the img element, then setting its src attribute. For example, using jQuery:
$("img#my-image").error(onImgError).prop("src", "images/my-image.jpg");
You won't get much information that way, just the fact that an error occurred while trying to load the specified element.
You can handle failures in jQuery.ajax requests by including an error callback function in the settings object passed to $.ajax. Be sure to wrap the code in both the success and error callback functions in try-catch.
Generally, you will want to protect your code with try-catch blocks so that you can catch and log errors. Handling window.onerror should be a last resort - for the things that slip through.
In your window.onerror handler, wrap everything in a try-catch block and ensure that you will not throw from the code in the catch block (using nested try-catches, if necessary).
The log handler sounds like a good idea, but I would limit the number of reports or tries that the report does. For example you don't want the reporter to have an error and then try to report it self over and over. Also if you have a bad client or a spike in traffic you dont' want to log too much.
Also, window.onerror won't work for iframes and I would do the xmlhttprequest, do you don't want to mess with the dom if you already having problems
TL;DR; Limit the client side requests and enforce limits at the server. window.onerror is no good for iframes, and use the xmlhttprequest.
We've recently started reporting unhandled errors as page-views to google-analytics. The basic idea is that a window.onerror handler would convert the error information (script file path, line number and error message) into a virtual error-page-url and report it as a page view. You can apply the logic to any page tracking mechanism.
The simple code we use is available on github at https://github.com/shyam-habarakada/js-watson
With all the analytical power of google analytics, and this simple technique, we've had great success in identifying the frequent and critical errors and been able to resolve them quickly. You can also use the power of GA to analyze trends in overall errors, specific errors in specific files, etc. etc. Highly recommended.

"Sys.WebForms.PageRequestManagerServerErrorException: status code: 500"

I am using an asp.net text box inside ajax update panel. If I enter &# in the textbox and press Save Button , it gives a javascript error
Sys.WebForms.PageRequestManagerServerErrorException: An unknown error occurred while processing the request on the server. The status code returned from the server was: 500
Please help me why this error appears?
Probably ASP.NET Request Validation kicked in and detected a potentially dangerous request (the &# in the textbox value). This causes an HttpRequestValidationException to be thrown - hence the 500 HTTP code is returned by the UpdatePanel. The way I see it there are two ways to solve this problem:
Validate the contents of the textbox and replace any potentially dangerous (HTML like) values.
Disable request validation:
<%# Page ValidateRequest="false" %>
If you choose to disable request validation make sure that the value of this textbox is not output verbatim somewhere else in your application. Make sure you are using HttpUtility.HtmlEncode when displaying it in order to avoid XSS issues.

Categories