Is there a way to get an automatic feedback if an error (even syntax errors) occurs when running a JavaScript on the client side?
I was thinking of something like this:
<script src="debugger.js"></script>
<script>
// some script with an error in it
</script>
And every time the debugger notices an error it sends a feedback to the server.
EDIT: I misunderstood your question initially, this should work:
Also note, this needs to go BEFORE any javascript that might cause errors.
window.onerror = function(msg,u,l)
{
txt ="Error: " + msg + "\n";
txt+="URL: " + u + "\n";
txt+="Line: " + l + "\n\n";
//Insert AJAX call that passes data (txt) to server-side script
return true;
};
As for syntax errors, you're out of luck. Javascript simply dies when there's a syntax error. There's no way to handle it at all.
One technique is to use Ajax for Javascript error logging
Every javascript error can be trapped in the window.onerror event. We can return true or false so we can choose if the user shall see the normal javascript error dialog.
This script will, in the very unlikely event of a javascript error, gather information about the error and send a httprequest to a page which will log the javascript error to the database.
I'm not sure about syntax errors but it is possible to catch js errors using window.onerror event. Searching for "logging errors in javascript" in google gives you a lot of results...
Logging JavaScript Errors To ASP.NET:
http://james.newtonking.com/archive/2006/05/02/Logging-JavaScript-Errors-To-ASP.NET.aspx
(Unfortunately the link to download in the post is broken).
Logging Client Side JavaScript Errors to the Server:
http://www.codeproject.com/KB/ajax/logclientsidejserrors2srv.aspx
JavaScript Error Notifications:
http://www.thecodepage.com/post/JavaScript-Error-Notifications.aspx
window.onerror = MyFunction(msg,url,line);
we pop up a window with the error details, browser type (i.e. navigator.userAgent), etc. all in fields marked READONLY and inviting the user to Submit them.
We have a checkbox "Don't show this again" which is stored in a session cookie - so if they keep getting errors than can disable the Popup.
Despite the fact that we thought this was "well cool", we get very few reports - and I'm not convinced that that is because we get close to zero runtime errors!
Probably best to send only one error report per page. If you get an error on a repeating timer, or the AJAX itself recursively calls an error, you can end up filling your log with useless junk.
Also, be prepared to receive unsolvable errors caused by things like:
security proxies diddling with your code
scripts from blocked sites
unimportant browser chrome errors from extensions
IE Mobile, the worst browser in the world
The easiest way for me was installing this app from SiteApps Marketplace:
http://siteapps.com/app/log_javascript_errors_with_ga-181
Once you've installed the platform tag, you can install a lot of apps and the one above is very useful for me. I use it in 14 websites that I developed and I could track javascript errors in Google Analytics.
Hope this can help.
Leandro
Related
as you may all-ready know lastError is a global variable or property from chrome.runtime API used for determining if some error happened during the chrome API call execution.
It is defined only when there was an error, if the API call is OK it won't be defined. The error can be triggered from multiple reasons eg. bad API call due to missing or wrong parameter type, or it can be caused by user interaction, eg. the user rejects permission granting by pressing the "cancel" button.
Chrome has unified it's error handling by using this variable for error reporting across their API's instead of returning an error argument. Due to it's API's async nature Chrome makes an additional check that validates if chrome.runtime.lastError is checked/handled in the callback function from the extension code, if not it throws the famous Unchecked runtime.lastError
You can quickly get the error message by checking chrome.runtime.lastError.message and display it to the user, and all of this is great for most use cases, but I wouldn't write this question if that were my case.
So what happens when you need to implement some additional code logic based on the error result. Let's take launchWebAuthFlow for an example, for the sake of simplicity of the question, I will focus only on the two possible outcomes/errors that can happen:
User interaction required. thrown when API call with bad argument value is made, in this case interactive = false
The user did not approve access. happens when the user closes the authentication window
So my question is, what will be the best way to implement additional logic based on the error?
Is a comparison of chrome.runtime.lastError.message the only way to do it, and if so, is it safe considering that the user browser language might be different than English.
What's your opinion, should Chromium dev team implement: chrome.runtime.lastError.code?
If a fetch call fails in Chrome, then the only error details that I get back is
TypeError: Failed to fetch
How do I display an informative error message to the end user in this case?
Specifically:
Is it possible to get any details about why fetch failed?
For example, if the server crashed, Chrome DevTools might log a console message of net:ERR_EMPTY_RESPONSE, but there appears to be no way to access this from JavaScript.
As far as I can tell, the answer is no; I assume this is for security reasons, to avoid letting malicious JS find out which sites are and aren't accessible by inspecting error messages.
Is it possible to distinguish fetch errors from other TypeErrors?
If I can't get error details, I'd like to at least replace the horribly vague "Failed to fetch" with an informative "Failed to access the web site; please try again later" message, and I'd like to do this without any risk of displaying that message for other TypeErrors.
The only solution I've found here is to check the actual message to see if it's "Failed to fetch". This is obviously browser-specific; it works in Chrome, it seems like it will work in any user language of Chrome, and other browsers would need their own testing and handling.
It seems likely that there aren't any more details for networking/permission/input problems.
Is it possible to distinguish fetch errors from other TypeErrors?
Yes, you just need to catch only the the errors from the fetch call:
fetch(…)
.catch(err => new FetchError(err))
.…
class FetchError extends Error {
constructor(orig) {
super();
this.message = "fetch error";
this.details = orig;
}
}
I'm playing around with implementing a JavaScript server ping tool based on the accepted answer given on this question: Is it possible to ping a server from Javascript?. This essentially works by assuming the pinged server is down if no response has been given after n milliseconds.
That's great, and it's a pretty cool way of doing it, however there are two rather large pitfalls:
Not all servers do respond within the allocated time.
Sometimes an ERR_CONNECTION_TIMED_OUT error is thrown before our timeout timer has finished.
Both of these things cause incorrect results. The former suggests that the server is offline when it's possibly online and responding slowly, and the latter suggests the server is online when it's (likely) offline.
In an ideal world this code would capture what type of error thrown was thrown and handle this appropriately. After all, if the error thrown is a 404 Not Found error, this counter-intuitively means the server is online and has responded.
If we log the image error event, the only thing we see surrounding the error is:
Event {
...
type: "error"
}
There's no message or anything hinting at what the error thrown was, and both the 404 and ERR_CONNECTION_TIMED_OUT errors give identical information.
What can I do to capture the ERR_CONNECTION_TIMED_OUT error I see in Chrome's JavaScript console, rather than relying on a fixed-speed timer?
Update
The best way I can replicate this issue is by altering Trante's JSFiddle demo (as linked to in the question I've linked above) to use a 30000ms timer rather than a 1500ms timer:
this.timer = setTimeout(function () {
if (_that.inUse) {
_that.inUse = false;
_that.callback('timeout');
}
}, 30000);
The 'unknown' server should obviously not respond, but instead we see this:
In Chrome's console, the following error has been thrown:
Failed to load resource: net::ERR_NAME_NOT_RESOLVED
As the Image's onerror function has been fired with the generic error as given above, the function believes this to mean that 1. 'unknown' exists, and 2. it's online. The ERR_NAME_NOT_RESOLVED error appears to be something which only Chrome is aware of, and isn't passed through to the error event at all.
Update 2
Today I tried doing this with web sockets instead of images and unfortunately these suffer from the same problem. The only data surrounding the error returned is type: "error" - no information about what the error actually was.
I am getting an error when I use JavaScript remoting and have my URLReWriter turned on on my Force.com SIte. The error does not occur when using JavaScript Remoting with the URL ReWriter turned off.
The error is as follows
Exception Error parsing json response: 'Unexpected token <'. Logged in?
I'm confused as to why this is occuring. If I have no checks for being logged in in my URL ReWriter (or visualforce page) why should this occur?
Has anyone ever come across something similar to this before? I noted the following https://salesforce.stackexchange.com/questions/4112/possible-oauth-remote-action-bug but in my case I am not using authentication on my site for the test page that I created & I'm wondering why it mentions "login".
Is it possible that URLRewriters and JavaScript Remoting currently do not work together in general?
Thanks in advance for any help on this.
Can you try debugging it server side? Add "your_site_name Guest User" to the debug logs and try the action. If you're lucky you'll see something going wrong (in the remote action? in rewriter?) and I suspect this uncaught problem causes a redirect to maintenance page (which will be HTML, not JSON)...
If not - use Firebug or similar tool to inspect request & response in detail? Or event.status?
Can it be something related to permissions? http://www.salesforce.com/us/developer/docs/pages/Content/pages_js_remoting.htm Or if you're returning html - I think you should have {escape:true}?
Does it happen in any browser? Maybe something doesn't like redirects caused by the URL rewriter. I've seen cases (not with Salesforce though) that antivirus software sometimes was adding some strange javascript at the end of certain websites and they had to be whitelisted...
The error may also happen due to parser error when page recieves status message from remote action function.
For example i tried Remote Action with attachment
#RemoteAction
public attachment attach(String body){
attachment a=new attachment();
a.body=body;
a.name='a.png'
insert a;
return a;
}
On the above code i receive error since SFDC does not parse the attachment object.SO if there are parser errors we get this message .
As a workaround i send as a wrapper .Hence i would suggest to investigate the return parameter of remote action and also wrapping it as workaround .
Hope this helps
My webapp currently employs a JS based error logging system for reporting JS error on the client side.
The problem with logging your error using javascript is just that - we are using a technology to monitor problems in that same technology.
Easily an error in the JS could prevent the logging from occuring.
I was wondering if anyone has an idea how we could log and report client side errors without relying on out own Javascript code.
thanks
Nope. But you can use a try / catch block to get out of javascript error that would otherwise stop execution.
try {
stuff.that('raises').error();
} catch(e) {
// send e via ajax
}
we are using a technology to monitor problems in that same technology
Don't we always do that. Have you ever done error and exception handling in a language other than the one you're working with?
Use window.onerror callback. Will also catch syntax errors. Or try catching the error as #Squeegy suggests.
Unfortunately, I don't believe that is possible. You will have to use javascript in some form to catch and report the errors, whether it be sending an ajax request, or having users submit a form with the errors in a textbox.