This is pretty much IE related because IE is the environment I'm using to test this, but I want to know if you can affect the relevancy of the error object properties when you throw an error. Consider the following javascript:
function MyClass (Arg1, Arg2) // Line 5 of my.js
{
if (typeof Arg1 != "string")
throw new Error("Invalid argument passed for MyClass");
// Do some other stuff here
}
Further down your code you have
var myvar = new MyClass(100, "Hello"); // Line 3201 of my.js
So the above would throw an error, but the error reported in the debugging information would show the error being thrown at line 9 of my.js instead of line 3201. Is this something you can change using standard methods?
What you are actually looking for is a stack trace for the error. There are no standards for this but most browsers do provide some means of discovery. Doing a quick search comes up with this js stack trace example.
In firefox you can use the stack property when you catch the error. In other browsers you can use the message property.
Have a look at this link on how to catch the stacktrace.
Related
I'm a JS game dev who's been trying to combat tampermonkey scripts for a while now.
I came up with a solution for people hooking into WebSockets where I'd cause the WebSocket to throw an error new WebSocket(0); (0 throws an error due to it being a number)
let output;
try {
output = new target(...args);
} catch(e) {
let source = e.stack.substring(e.stack.indexOf("("), 1 + e.stack.indexOf(")"));
e.stack = e.stack.replace(source, "nothing to see here");
throw e;
}
this code made the error's stack have all the information I was looking for replaced!
I've been looking at Object.defineProperty, and I was wondering how I could stop an error's stack from being modified before I have access to that specific error. And if anyone has any other ways I could stop a script from being loaded or run, I'd love to hear them!
One thing you could do is Object.freeze the error before throwing it. This would prevent people from altering the object's contents.
So for example:
try {
new WebSocket(0);
} catch (wsErr) {
throw Object.freeze(wsErr);
}
The code catching your error and trying to alter it would fail to be able to alter it. This should work as it will cause the code that was altering the error to throw with the following:
Cannot assign to read only property 'stack' of object ''
The other thing you'll have to consider is that in your code where you're catching the error, you will not be able to alter its contents either. Typically with errors, that's not a huge deal though. Tampering with errors is one of the only reasons I can think of for modifying the error.
JavaScript, when throw-ing a built-in error as such:
throw new Error("Something was wrong");
displays the text nicely - you can't tell you threw an object
However, when creating a custom error by subclassing the Error object (or other error object for that matter), the thrown error is not displayed the same way in the console.
So, by using this code:
var ImproperlyConfigured = function(message){
this.name ="ImproperlyConfigured";
this.message = message || "The object you tried to construct was improperly configured due to an unknown error";
}
ImproperlyConfigured.prototype = new Error();
The following is the output
I don't like the fact that the object properties (name and message) are shown. In fact, I don't like that I don't understand why the properties are shown.
I've googled a bit and I got the feeling that by implementing a toString method will help but, by using this method, the fact that the name of the error is no longer in red puzzles me even more.
Code
var ImproperlyConfigured = function(message){
this.name ="ImproperlyConfigured";
this.message = message || "The object you tried to construct was improperly configured due to an unknown error";
this.toString = function(){
return this.message;
}
}
ImproperlyConfigured.prototype = new Error();
Output:
What I would like to achieve is a standard looking error, by the use of custom error and, of course, by not using the console.error method manually in a try...catch block.
Is this possible?
As Pointy correctly pointed out (pun intended), the issue here is not with JavaScript, but rather with the environment JavaScript is running (in this case, Google Chrome).
In another environment (like Chromium, Firefox, NodeJS, etc.) the behavior will likely be different, using the same code, depending on how those JavaScript hosts are handling these cases.
How do I print the stack trace of an Exception in the chrome devtools from my code?
I tried the following:
function doSomething() {
undefined(); // This throws an exception
}
try {
doSomething();
} catch (e) {
console.error("Exception thrown", e);
}
But this yields the following result:
Exception thrown TypeError {}
And if I expand the arrow next to it, it points me to the line where the console.error() call was made, so I don't get to see where the original error actually happened.
What would be the best way to include the original error information (including message and complete stack trace to the exact location where the error happened) in the console output?
Object Error has a property stack. Print it out.
console.error("Exception thrown", e.stack);
Please note that stack property is not standardized and it is only used by V8 based browsers + IE. Firefox uses different convention.
You can output the error as object
console.error("%O", e)
Using string substitutions
UPDATE
[Rewriting question to focus on the problem I am trying to understand.]
Is there a means in JavaScript to throw Exceptions that notify the line number where the problem occurs? Similar to C#'s debugger, if an error is thrown on line 50 then I will be taken to line 50.
For example, according to MDN EvalError represents an error with eval(). So, let's say I have a function that uses eval(). I want to use a specific error that is representative of the problem at hand, EvalError:
//As written here the error implies there is a problem on this line. See Firebug console window
var evalErra = new EvalError('required element missing from evaluation');
var stringFunc = "a=2;y=3;document.write(x*y);";
EvalString(stringFunc);
function EvalString(stringObject) {
//Some arbitrary check, for arguments sake let's say checking for 'x' makes this eval() valid.
if(stringObject.indexOf('x') !== -1) {
throw evalErra;
//throw 'required element missing from evaluation';//This way offers no line number
}
eval(stringFunc);//The problem really lies in the context of this function.
}
If I'm going about this all wrong, then please tell me how I should approach these kinds of issues.
When you throw an error, execution of the current code will stop and JS will work its way back up the execution tree until it finds a catch () which handles the particular type of error being thrown, or gets all the way up to the top of the tree, causing an "unhandled exception" error: You threw an error, and nothing caught it, and now someone's window got broken.
try {
if (true) {
throw 'yup'
}
} catch (e) { // catches all errors
... handle the error
}
When doing error handling you want to do the following
throw new Error("message");
Then if you ever handle this error look at err.stack (firefox/opera/chrome) or err.line (Safari) or err.IE_Y_U_NO_SHOW_ME_ERROR_LINE_NUMBER (IE) to find the line number.
If you want you can subclass Error.
Javascript has this great callback window.onerror. It's quite convenient to track any error. However, it calls with the error name, the file name and the line. It's certainly not as rich as getting the actual error object from a try...catch statement.
The actual error object contains a lot more data, so I am trying to get that. Unfortunately, try...catch statement do not work fine when you start having async code.
Is there a way to combine and get the best of both worlds? I initially looked for a way to get the last error triggered within an onerror block, but it looks like JS doesn't store that.
Any clue?
this is now possible in some browsers.
The spec was updated to include the actual error with stacktrace as the 5th parameter.
the problem is that not every browser supports this yet, so you could do something like this:
window.onerror = function(message, filename, lineno, colno, error)
{
if(error != null)
{
//handle the error with stacktrace in error.stack
}
else
{
//sadly only 'message', 'filename' and 'lineno' work here
}
};
If you're referring to stack trace of the error object, then AFAIK, this is not possible.
Simple reason being that a stack trace is related to an execution context in which runtime exceptions (handled with try...catch...finally) were created or thrown (with new Error() or throw).
Whereas when window.onerror is invoked, it is called within a different context.
You can get some mileage by inspecting window.event (not available on FF) in your onerror handler.
Modern browsers fully support the HTML 5 draft spec for ErrorEvent and window.onerror. In both of these browsers you can either use window.onerror, or (amazingly!) bind to the 'error' event properly:
// Only Chrome & Opera pass the error object.
window.onerror = function (message, file, line, col, error) {
console.log(message, "from", error.stack);
};
// Only Chrome & Opera have an error attribute on the event.
window.addEventListener("error", function (e) {
console.log(e.error.message, "from", e.error.stack);
});