When catching an error, I want to get with the stack trace the actual code of the line that triggered the error.
Given that I have the path to the file and the line number throwing the error, what's the best way to also get the actual code of that line?
Beyond the obvious of "looking it up in the file", there are a few things you can do to get it automatically. Checkout the Tracekit project on GitHub. For errors it captures, it will do an AJAX request for the script and find the relevant lines in the text.
Alternatively, if you're looking for a way to handle this automatically, you should consider a service like TrackJS that will capture all the relevant scripts and apply sourcemaps for you. I am one of the original developers and I've used it on many projects to fix bugs ridiculously fast :)
Related
firstly very sorry, I cant find out what the real problem is.
I ll try to explain.
My client given code which is developed using opencart and nitropack.
he includes common.js in header, it is basic js file with some ajax calls, UI events etc which has 1297 lines(no formating in code, lots of blank spaces, blank lines etc).
my real problem is, when I made any changes in this file,
the browser console is throwing error invalid or unexpected token.
I checked the common.js file in browser console, seeing that some kind of reddots added at last of the file. I just added a alert() at the begining of file. nothing else.
very sorry, dont know how to explain more detaily.
This is the first time I have seen this kind of issue.
when I removed the alert(), the error gone.
I am new to wala. Trying to configure it by following steps given at wala: gettingstarted.
However, I have to face errors on each example I am trying to run. Please look at following errors:
1- Example SWTTypeHierarchy
PANIC: roots.size()=0
2- Example PDFTypeHierarchy
spawning process [C:/Program Files (x86)/Graphviz2.38/bin/dot.exe,
-Tpdf, -o, D:\WALAOut\th.pdf, -v, D:\WALAOut\temp.dt] process terminated with exit code 0 read 919 bytes from error stream
3- Js frontend com.ibm.wala.cast.js.rhino.test-JUnit
I am not able to use launcher instead when I open it following error is there
" [JRE]: Unknown JRE type specified:
org.eclipse.jdt.internal.launching.macosx.MacOSXType"
I am not sure which step went wrong which have completely damage the execution. Please help
It is hard to help you with these generic problems. I will give it a try based on the limited information these error messages contain.
1) have you configured your wala.properties file?
2) you are missing dot for this visualization. Hence the error. You may also want to use http://pages.cs.wisc.edu/~ghost/gsview/ to view your graphs.
3) seems like a problem with the location of the jre, how did you configure your properties file?
The WALA examples are great to learn from, but sometimes getting one of them to run is more time consuming, than using the slicer example in their wiki page:
http://wala.sourceforge.net/wiki/index.php/UserGuide:Slicer
This should get you started more easily.
I am finding it difficult to locate where an error occurs in javascript on a client I have no access to. Currently I trap the error with onerror and send the arguments to a log on the server.
Unfortunately the line number is no help because numerous javascript files get included, causing the line number to not correspond to anything I have access to.
So if I get something like "n is not defined", and n occurs many times in the function, I have no way to locate where it happened.
I have been trying to reference the code on the line throwing the error say "x=n * 5 + 4", then I could search for that code, but have had no luck referencing the actual code on a line from within javascript.
So how does one locate the line that threw the error in this situation?
client uses firefox only, if that matters.
I have no access to client
This is not one error I am stuck on, but working on how to track an error in this situation
Your best bet would be to use Firefox's debugger.
Open dev tools
Go to the debugger, select the .js file you want, and hit the little {} button in the bottom left (depending on version yours may be in a different location) -- this will prettify the JavaScript
Set breakpoints by clicking next to line numbers
From here on out you have to do this old-fashioned. Cast a breakpoint net around your trouble code, then keep narrowing down the lines until you find the occurrence that causes the error.
Of course, once you find the line it still won't be 1-to-1 with the original code, but hopefully the breakpoint exercise will at least reduce the scope of code/logic you have to dig through.
use your debugger to enable breaking on error. once you break, look at your locals for clues about your location. go up the stack and look at each frame.
you should be able to trace n up the stack and find out why it was null
the little {} that william suggested is also helpful
I catch JS errors by subscribing to window.onerror event, so if someone catches 'undefined variable' error, I send it to server for debugging purposes.
As you know this event return 'message of error', 'url' and 'line' where error occurred.
The problem are in compressed files.
If file is compressed, all the code goes in one line and it's big problem to determine the exact place of error.
Is there any solution for this problem?
JavaScript compressors usually do two things:
Remove all unneccessary white-space (“unneccessary” in terms of syntactical validaty).
shorten variable names, if possible. This applies to local variables, i.e. those which are not in the global scope or members of an object.
There are some other optimizations, such as function inlining, but these are usually not so problematic.
As for the first point, you can run the code through one of the many JavaScript source formatters. This should give you a pretty readable JavaScript file.
As for the second point, the obfuscation is usually not reversible. If “speaking” variable names like width, height or whatever have been changed to a or b, you cannot know what they were meant to express in the first place.
If this problem applies to an open source product, you can usually download the sources and try to reconstruct the problem with them.
If it's closed source, and only “beautifying” the code doesn't help, you have to write a bug report to the vendor.
No. There is no way to "unminify" a JavaScript include for the purposes of error logging.
Your best bet is probably to log the Error Type in the hope that this will help you debug the problem.
If you really want to get to the specific line number you would have to remove the minimization and rely on browser caching to attain performance.
I think you could use source maps...
Its a file that can be generated when minifying, and can be used to map the line/character of the minified file to the original source.
http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/
The best answer regarding this question I found here
Malyw suggests yo use Uglify with max-line-len option and sourcemaps.
That's probably the best solution to identify exact place in code
This is a beginner's question -- surely already answered but I don't know how to find it:
When a coding/system error message pops up during processing of a PHP script or possibly JavaScript, its title is usually "The page at localhost [or other URL] says:". Its content usually includes a load of non-rendered HTML code (<b>, <br>, etc), a long reference to a PHP manual, an actual error message, and a reference to where the error occurred. Because the HTML is being ignored, the whole dialog is hard to read.
How can I get such windows to appear styled properly, as surely intended by the "folks at PHP or JavaScript", or at least appear in simple text with line breaks?
Please note: It is not an error message that I am intending to pop up in response to any user action; I don't know what is causing the message. Also, I'm not seeking advice on how to make user-friendly software or on how to do continuous development-and-delivery
How can I get such windows to appear styled properly, as intended?
I don't know which window you are talking about, however from the rest of your description it sounds to me that you want to turn HTML error off so to get the plain text version of the error messages.
PHP has a setting for that Docs:
html_errors boolean
Turn off HTML tags in error messages. The new format for HTML errors produces clickable messages that direct the user to a page describing the error or function in causing the error. These references are affected by docref_root and docref_ext.
So all you need to do is to turn if off, either in your php.ini:
html_errors = 0
Or within your code:
<?php
ini_set('html_errors', 0);
You might also be interested in:
How to get useful error messages in PHP?
Never have your errors show up in a production website!!
If you're talking about dealing with errors while you're developing, then check out the Whoops library. It'll give you everything you want, plus much more.
Here's a quote from their homepage:
whoops is a nice little library that helps you develop and maintain your projects better, by helping you deal with errors and exceptions in a less painful way.
Check out their demo here. You can click on the left side to go through the stack. Really cool.