We Keep Coding

ES6 Proxies: trapping undefined function executions

Let's say I have the following object with two functions as properties:
const foo = {
f1: () => {...},
f2: () => {...},
}
I would like to perform a specific action (for example, throw a custom error) when someone tries to execute a function that doesn't exist on the foo object.
I've tried using a get proxy, but that throws an error even when I'm not trying to execute f3, such as in the following code:
if (foo.f3) {...}
So how can I write my proxy in such a way that foo.f3 returns undefined as it usually would, but foo.f3() does throw an error?

Here's a partial solution, inspired by Unmiss.
const handler = {
get: function(obj, prop) {
if (prop in obj) {
return obj[prop];
} else {
return () => {
throw new Error(`Foo.${prop} is undefined`);
}
}
}
};
The problem with this is that while it accomplishes the goal of only throwing an error when you actually try to execute Foo.f3(), since Foo.f3 is now equal to that anonymous function is doesn't return undefined anymore, meaning that (as far as I can tell) if (Foo.f3) {...} will always return true.
Edit: as #paulpro points out:
You absolutely cannot do that. foo.f3 is either undefined or some
callable with custom logic; it cannot be both.
The best we could do is trap f3 in foo statements using the has trap, but this would mean if (f3 in foo) and if (foo.f3) would now have different results, which seems like a big red flag.

Is this what your asking for?
https://jsfiddle.net/MasterJames/bhesz1p7/23/
[obviously you need to F12 your dev tools to see the console output or change as desired]
Only real difference is to return undefined after throwing. It's as if the function executed without doing anything since it doesn't exist.
I'm sure there's a different solution based on the actual use case, but I like the idea/question. Keeps things more stable etc.
let foo = new Proxy(
{
f1: function (val) {
console.log(' F1 value:' + val);
return 'called OKAY with', val;
}
},
{
get: function(obj, prop) {
console.log("obj:", obj, " prop:", prop);
if (prop in obj) {
console.log("Found:", prop);
return obj[prop];
}
else {
console.log("Did NOT find:", prop);
throw new Error(`Foo.${prop} is undefined not called returning undefined`);
return undefined;
}
}
});
console.log("\nFoo Tester started");
console.log(' Does F1 exists', foo.f1 !== undefined);
console.log(' called F1 result:', foo.f1('passed') );
try {
console.log(' Does F2 exists', foo.f2 !== undefined);
console.log(' called F2 result:', foo.f2('passed') );
}
catch (err) {
console.log(' Error calling F2:', err );
}
console.log("Foo Tester finished");
Not sure you want to try-catch or not that's also up to you so in the end checking if it's real and a function is the same difference depending on how your going to handle the error.
if (foo.f2 && foo.f2.constructor === Function && foo.f2()) console.log("okay!");
Again you call build a safeCall wrapper more like this or something in between?
possible calling foo's 'customThrow' if it exists or what-have-you, so many possibilities with JS.

Okay so it took me sometime but I have a solution now.
I was not fully understanding your question, which I reformulated as a question within the question for myself to understand the issue better as it is complicated.
Basically you want to know if it's being called or not so the function you need in the proxies 'get' is 'isCalling'.
The solution is not clean in JS Fiddle because it's messy there at least for this kind of problem's solution.
Basically the solution is a sentence is, "you have to use an error to get a stack trace then retrace the source code that is calling and look for a right bracket or not.", to determine how it's being called and return whatever you want then).
[Please note this depends on your code and how you call it so you would adjust as needed.]
Since you have to find the location in the source code that's being called from it's way better if there is no inline script tag as is the case in this JSFiddle example. I'm using outerHTML to get the source, when arguments.callee.caller.toString() is better from an actual JS file. You'll also not the location from the stacktrace is skewed by odd behavior here, so with a normal JS file the code would align properly using other solutions are recommended. If anyone knows how to get a clean source that aligns with the error trace every time with script-tag blocks etc. Also note coming but not existing yet are things like Error.lineNumber.
[Please don't bother with the version history it was a nightmare to sort this one out. And again you would be better to use other npm packages to do the source code from stack trace parts.]
Anyway the example I believe achieves what you want but in principle demonstrates what you'd need to do better in a given real (no Fiddle) situation. I'm pretty sure doing this is not a great solution in production either and I've not tested the timing (performance speed) but if it really was that important to your cause (and no other better solution which I doubt) then it will work.
Originally I discovered this technique when I was doing something experimental, and instead of just sending another argument I was checking to see what was actually calling it and adjusting the functions action depending.
Usages are extensive when you start to think more about it as I did last year when I first did something like this. Examples are as an extra function execution Security Check, Realtime mystery-bug Debug Solution, a way to execute the function differently without passing more arguments, runaway recursive loops (how long is the stack), to name a few.
https://jsfiddle.net/MasterJames/bhesz1p7/90/
let foo = new Proxy(
{
f1: function (val) {
console.log(' F1 value:' + val);
return 'called OKAY with', val;
}
},
{
isCalling: function() {
let stk = new Error();
let sFrms = this.stkFrms(stk.stack);
console.log("stkFrms:", sFrms);
//BETTER From real pure JS Source
//let srcCod = arguments.callee.caller.toString()
let srcCod = document.getElementsByTagName('html')[0].outerHTML.split("\n");
let cItm = sFrms[(sFrms.length - 1)];
if(cItm !== undefined) {
let cRow = (parseInt(cItm[1]) - 3);
let cCol = (parseInt(cItm[2]) + 1);
let cLine = srcCod[cRow];
let cCod = cLine.substr(cCol, 1);
if(cCod === '(') return true;
}
return false;
},
stkFrms: function (stk) {
let frmRegex1 = /^.*at.*\(.*\:([0-9]*)\:([0-9]*)\)$/;
let frmRegex2 = new RegExp(frmRegex1.source, 'gm');
let res = [], prc, mtch, frms = stk.match(frmRegex2);
for(mtch of frms) {
prc = frmRegex1.exec(mtch);
res.push(prc);
}
return res;
},
get: function(obj, prop) {
if (prop in obj) {
console.log("Found:", prop);
return obj[prop];
}
else {
if(this.isCalling() === false) {
console.log("Did NOT find:", prop);
return undefined;
}
else {
console.log("Did NOT find return custom throw function:", prop);
return function() {throw new Error(`Foo.${prop} is undefined`);}
}
}
}
});
console.log("foo.f1:", foo.f1);
console.log("foo.f1('passed'):", foo.f1('passed'));
console.log("foo.f2:", foo.f2);
try {
console.log("foo.f2('passed2'):", foo.f2('passed2'));
}
catch(err) {
console.log("foo.f2('passed2') FAILED:", err);
}
console.log("'f2' in foo:", 'f2' in foo);
Okay so a verbal run through:
You want to check foo.f2 is undefined so it returns that because it's not being called.
If you do call it (f2) without simply checking first and erroring as needed, and you don't want to try-catch to throw your custom error based on the function name, you want it to return an actual function that will throw a custom error.
You also want to use 'in' to see that it's undefined, which is the same as false (maybe hack it further to send false instead of undefined via something like isCallingFromIn too.
Did I miss anything? Is this not what you all thought was impossible?

Extending the native JavaScript Error constructor

I tried to extend the JavaScript error properties through the extension of the prototype of the Error constructor:
<script type="text/javascript">
// extending the Error properties to all the ones available in the various browsers:
Error.prototype = {
name: null, // (all browsers); the name of the error
message: null, // (all browsers); the error message as a string
description: null, // (Internet Explorer); description of the error
fileName: null, // (Firefox); the name of the file where the error occurred
lineNumber: null, // (Firefox); the number of line where the error occurred
columnNumber: null, // (Firefox); the number of column where the error occurred
number: null, // (Internet Explorer); the error code as a number
stack: null // (Firefox, Chrome); detailed information about the location where the error exactly occurred
};
function log(error) {
var errors = [];
for (var prop in error) {
errors.push(prop + ': ' + error[prop]);
}
alert(errors.join('\n'));
}
</script>
Then I test the log function:
<script type="text/javascript>
try {
var a = b; // b is undefined!
} catch(error) {
log(error);
}
</script>
The result is that the error object only shows some properties (e.g. on Firefox fileName, lineNumber and columnNumber) like if it has not been extended.
But the most strange thing is that the for...in cycle seems unable to walk all the error object properties: trying to alert the standard property error.message normally returns a message.
So the results of my test are:
the Error constructor is not extensible through its prototype, as other native constructors are;
the for...in loop is not able to walk the properties of an error object.
Am I right?
Are there some interesting evidences/resources you may suggest to know more about it?

A. Like, Raynos said, The reason message isn't being set is that Error is a function that returns a new Error object and does not manipulate this in any way.
B. The way to do this right is to return the result of the apply from the constructor, as well as setting the prototype in the usual complicated javascripty way:
function MyError() {
var tmp = Error.apply(this, arguments);
tmp.name = this.name = 'MyError'
this.stack = tmp.stack
this.message = tmp.message
return this
}
var IntermediateInheritor = function() {}
IntermediateInheritor.prototype = Error.prototype;
MyError.prototype = new IntermediateInheritor()
var myError = new MyError("message");
console.log("The message is: '"+myError.message+"'") // The message is: 'message'
console.log(myError instanceof Error) // true
console.log(myError instanceof MyError) // true
console.log(myError.toString()) // MyError: message
console.log(myError.stack) // MyError: message \n
// <stack trace ...>
The only problems with this way of doing it at this point (i've iteratted it a bit) are that
properties other than stack and message aren't included in MyError and
the stacktrace has an additional line that isn't really necessary.
The first problem could be fixed by iterating through all the non-enumerable properties of error using the trick in this answer: Is it possible to get the non-enumerable inherited property names of an object?, but this isn't supported by ie<9. The second problem could be solved by tearing out that line in the stack trace, but I'm not sure how to safely do that (maybe just removing the second line of e.stack.toString() ??).

Handling JavaScript exceptions from Silverlight

I'm having trouble adding proper exception handling to existing code that makes heavy use of Silverlight - JavaScript interoperability. In this case, my JavaScript can throw an exception that I want to handle meaningfully in Silverlight.
From Silverlight, I'm creating an instance of a JavaScript object, then later I'm calling a method on that object:
public class MyWrapper
{
dynamic _myJSObject;
public MyWrapper()
{
_myJSObject = HtmlPage.Window.CreateInstance("MyJSObject");
}
public int MyMethod()
{
try
{
int result = (int)_myJSObject.MyMethod();
}
catch (Exception ex)
{
// I want to add meaningful exception handling here
}
}
}
Whenever MyJSObject.MyMethod throws an exception, there are two problems:
The browser shows a message that an exception has occurred.
Information about the exception is not passed to my managed code. Instead I get a RuntimeBinderException which just says "Cannot invoke a non-delegate type" and contains no other information whatsoever. This does not seem to match what is described here; I'd expect an InvalidOperationException.
I've tried avoiding to cast the returned value of the method:
object tmp= _myJSObject.MyMethod();
This makes no difference. Changing the type of exception thrown on the JavaScript side has no effect either.
MyJSObject.prototype.MyMethod = function ()
{
throw "Hello Silverlight!";
}
The only solution I can think of right now is abusing the function's return value to pass information about the exception, but that will make my code a whole lot uglier... so:
Why is the behavior I'm seeing different from what is described in documentation? Does it have to do with my use of dynamic somehow? How can I properly handle exceptions that occur in JavaScript in my managed code?

After quite a bit of experimentation, I concluded that there is no way to directly handle the JavaScript exception from Silverlight. In order to be able to process the exception, the JavaScript code needs to be changed slightly.
Instead of throwing the error, I return it:
function MyMethod()
{
try
{
// Possible exception here
}
catch (ex)
{
return new Error(ex);
}
}
Then on the Silverlight side, I use a wrapper around ScriptObject to turn the return value into an exception again. The key here is the TryInvokeMember method:
public class ScriptObjectWrapper : DynamicObject
{
private ScriptObject _scriptObject;
public ScriptObjectWrapper(ScriptObject scriptObject)
{
_scriptObject = scriptObject;
}
public override bool TryInvokeMember(InvokeMemberBinder binder, object[] args, out object result)
{
result = _scriptObject.Invoke(binder.Name, args);
ScriptObject s = result as ScriptObject;
if (s != null)
{
// The JavaScript Error object defines name and message properties.
string name = s.GetProperty("name") as string;
string message = s.GetProperty("message") as string;
if (name != null && message != null && name.EndsWith("Error"))
{
// Customize this to throw a more specific exception type
// that also exposed the name property.
throw new Exception(message);
}
}
return true;
}
public override bool TrySetMember(SetMemberBinder binder, object value)
{
try
{
_scriptObject.SetProperty(binder.Name, value);
return true;
}
catch
{
return false;
}
}
public override bool TryGetMember(GetMemberBinder binder, out object result)
{
try
{
result = _scriptObject.GetProperty(binder.Name);
return true;
}
catch
{
result = null;
return false;
}
}
}
Potentially you could improve this wrapper so it actually injects the JavaScript try-catch mechanism transparently, however in my case I had direct control over the JavaScript source code, so there was no need to do this.
Instead of using the built in JavaScript Error object, it's possible to use your custom objects, as long as the name property ends with Error.
To use the wrapper, the original code would change to:
public MyWrapper()
{
_myJSObject = new ScriptObjectWrapper(
HtmlPage.Window.CreateInstance("MyJSObject"));
}

Executing try/catch on different Window in IE

Consider a page containing an iframe. The iframe's content might look like this
<script type="text/javascript">
window.foo = function () {
nonExisting();
};
window.bar = function () {
throw "An error!";
};
</script>
Now, I wanna execute something like this:
try {
iframe.contentWindow.foo();
} catch (e) { console.log('ok'); }
and
try {
iframe.contentWindow.bar();
} catch (e) { console.log('ok'); }
This is what I get:
Chrome/Firefox/Opera - 'ok', 'ok'
(expected behaviour)
IE8 - "Object expected" error, Uncaught Exception
WTF is going on here? How could that be an uncaught exception when I'm using a try/catch block? Is that a bug? Or does anything in the specs allow this behaviour?
And most importantly: Can I make it work as it should?

That's because you have a typo: "An error"!.
If I run it without that typo on IE9 with IE8 emulated, it works: http://jsfiddle.net/vsSgE/3/.

I ran into this exact issue today. I had defined a couple of "exception classes" in the parent window, which I "imported" into the child window (iframe) to be able to handle them with instanceof in the parent. Something like this:
Parent window
window.MyExceptions = {
RenderingException: function () { ... }
// ...more exception types
};
// Somewhere further down in the code, assuming 'iframe' is the child iframe
try {
iframe.contentWindow.renderAllTheThings();
} catch (ex) {
if (ex instanceof MyExceptions.RenderingException) {
// ...
}
}
Child (iframe) window
window.MyExceptions = window.parent.MyExceptions; // Import exception types
window.renderAllTheThings = function () {
// ...
throw new MyExceptions.RenderingException();
};
Using this setup, I got the same problem as you did - it worked in all modern browsers I tested, but failed in IE8 with the "uncaught exception" error.
My workaround was to add a simple utility function to the MyExceptions object in the parent window that does the actual throwing, like this:
window.MyExceptions = {
RenderingException: function () { ... },
// ...more exception types
Throw: function (ex) {
throw ex;
}
};
Then whenever I wanted to throw an exception from the child window to be handled in the parent, I would do MyExceptions.Throw(new MyExceptions.RenderingException());.
Not exactly elegant, but I needed to get it working.

chrome exceptions object (nearly) empty

I'm trying to get useful information from the exception object (passed to the a "catch") and it is nearly empty in chrome. I have used it before and was able to get a reasonable stack trace, among other things. Is this a change to chrome, or am I doing something wrong? I'm doing this:
http://jsfiddle.net/R9Wkg/
function pr(s) {
document.body.innerHTML += s.toString() + "<br>";
}
function test() {
try {
var a = b; // err: b not defined
} catch (ex) {
pr('==== print exception object =====');
pr(ex);
pr('======= typeof exception object =====');
pr(typeof ex);
pr('===== members ======');
for (var i in ex) {
pr(' ----- ' + i + " ------");
pr(ex[i]);
}
console.log(ex);
}
}
function first() {
second();
}
function second() {
test();
}
first();
In Chrome it gives me nothing more than the string "ReferenceError: b is not defined" if I do a toString() on the exception object, but if I try to look at the object's individual members, there is nothing there. Notably there is no "stack" member. Then again, if looked at in the console, there is more there (but the stack is simply "-")

That hyphen means it's a getter, and is not automatically executed because it could have side effects. You can log them separately however: http://jsfiddle.net/R9Wkg/1/.
The fact that the error isn't enumberable is filed as an issue at V8's project site.

You can get the members of the error using Object.getOwnPropertyNames(ex) to enumerate them.
pr('===== members ======');
Object.getOwnPropertyNames(ex).forEach(function(i) {
pr(' ----- ' + i + " ------");
pr(ex[i]);
});
http://jsfiddle.net/gilly3/R9Wkg/3/