There is a log entry saying that there is an error on client side, however, the errors are not shown in Firebug.
Where can I see error details?
What you are seeing in an internal error generated by the google drive framework. It's not necessarily a critical error--the framework seems to discard the error.
Firebug does not show an indication of an error, because the message you're seeing is generated by the console.log function (i.e. it's not a javascript compilation error.)
If you could share the code, perhaps it would be easier to say how the error was generated.
Related
Every time I called Office.context.mailbox keeps returning error code 9020. I see in some articles that the error was fixed but I didn't anyone saying what was the source of the issue. How may I avoid this issue?
According to the Office.context.mailbox.item.body.getAsync returns error 9020 An internal error has occured page:
This issue was reported for OWA and the fix went in OWA client.
If you still have got the same error I'd suggest posting/file a bug on the office-js repo on github.
After making some coding changes in my project and refreshing the page, I encountered the error below:
This tells me that the file loan.js could not be found. My first thought, then, is to find out what file is trying to make a call to loan.js. When I expand any of those errors to view the stack trace, I see system files like:
system.src.js:xxx
aurelia-loader-default.js:xxx
aurelia-templating.js:xxx
compose.js:xxx
etc
What does not show up is any specific file that would lead me to where my error is. It turns out that in myFile.js
I had forgotten to provide the specific path to loan.js
view-model="loans/loan"
With multiple view models and views where we make references like the above, how are we expected to debug issues like this when the communication is not specific? Is there some debug, logging error options that I am missing? I'm used to compilers at least providing the last place where the file was attempted to be fetched (causing the 404).
I am just getting started with Play Evolutions and I find it pretty tough to figure out why they fail and leave the DB in an inconsistent state.
In Dev mode it will display the error in the default HTML page but it does not say which statement failed. This is also problematic since for this particular application I only have REST APIs that return JSON and so an HTML error is not appropriate. I have my own error handler so I will probably end up matching on ExceptionAttachment and pull out the content/script myself and escape that in the JSON error response. However this is only in DEV mode since I would not want this going back to a real user in PROD.
More frustrating is that it doesn't even log the statement when it fails. I can enable logging for my driver but once the failure has occurred it is too late to then go and enable logging.
Is there anyway to get a more specific error in the logs when an evolution fails?
Is there a way in Codeigniter to override global errors. For instance if an DB error or PHP critical occurs it wont show the error itself but something like 'Our admin guy is fixing the issue' and the error is just logged and emailed.
Codeigniter lets you handle error messages your way, depending on the HTTP status.
Refer to this documentation on error handling
In addition to #Pos5e5s3dFr3ak's answer, you should handle as many errors as you can manually. For example, if you have a database error, your code should acknowledge (or 'catch') it and perhaps load the appropriate view, or pass it onto a library that will log an email the fault, instead of displaying the intended result.
This method can be used as an alternative, or as an addition to the original answer - sometimes you need not locate the error just by its HTTP response Status Code.
As an example, you may find that the database engine in use is down. If this is the case (you would have to determine if it is indeed down - ie. you are not getting the desired response), you would pass the user on to example.com/error/database, for example.
I have a Classic ASP/VBScript site running on IIS 6, and a program called SmarterStats (found via an earlier question) providing various stats and info from the server logs. This is an internal site, and we do use integrated authentication (AUTH_TYPE = Negotiate).
I'm looking at the report on response codes, and it says that in the last 7 days there have been 255 responses with a 5xx error code... naturally not the most useful stat I could get back.
I have a custom error page for 500 and 500.100 errors that logs the specifics for me to follow up on - and that log is virtually empty. I've tested with an intentionally broken page, and a standard user account, and it is working as expected - custom message, log entry made. (and checked with "friendly error messages" on and off - works either way)
The only entry I have in the log is a single entry for an error -2147024843 (authentication related, took too long to get a response), and that's it... what other errors could be happening and how can I find/track them?
Should I route all the different types of 5xx errors through my custom page? Or is there something else I should be doing?
Resolution: I'm going to go with running all 5xx errors through the custom page. For reasons that leave me totally baffled, the errors have stopped... I've not changed anything, no one has changed anything on that server - but the errors have stopped. Go figure.
It seems like logging all 5xx errors via your custom page might be a good idea. Your logging seems to be working, but SmarterStats seems like it might be giving you bogus data?
What version of SmarterStats are you using?
My hosting provider has Version 5.2 and I can see a detailed list of which pages have produced a 5xx error by going to Report Items > Server Responses > 5xx - Server Errors in the navigation tree. The report that gets displayed has a table listing the pages that have produced the error codes so you can then go investigate those pages to see what may be causing the error.
Depending on your site the error might be perfectly normal, for example I have some custom HTTP handlers which implement a standardised HTTP protocol which actually specifies that 5xx errors should be thrown under certain circumstances.
Though this shouldn't apply to an internal only site on public websites it is sometimes the case that badly written crawlers will access your pages in such a way as to produce an error