|
|
| Line 62: |
Line 62: |
|
| |
|
| Similarly, there are places where Python adds additional information to error messages to ease debugging, which inspire our own library design. In Cuddlefish's <tt>file</tt> module, for instance, we report the ''name'' of files that don't exist when throwing errors, as opposed to simply using static "file does not exist" text and forcing the developer to figure out the filename on their own (which is effectively what <tt>NS_ERROR_FILE_NOT_FOUND</tt> communicates). | | Similarly, there are places where Python adds additional information to error messages to ease debugging, which inspire our own library design. In Cuddlefish's <tt>file</tt> module, for instance, we report the ''name'' of files that don't exist when throwing errors, as opposed to simply using static "file does not exist" text and forcing the developer to figure out the filename on their own (which is effectively what <tt>NS_ERROR_FILE_NOT_FOUND</tt> communicates). |
|
| |
| '''I get full tracebacks for errors, but they appear to be missing the portion of the stack inside my capability code. Here's one such stack:'''
| |
|
| |
| <pre>error: An exception occurred.
| |
| Traceback (most recent call last):
| |
| File "resource://cuddlefish-jetpack-cuddlefish-jetpack-cuddlefish-jetpack/main.js", line 39, in
| |
| dump(f.read() + "\n");
| |
| File "resource://cuddlefish-jetpack-secure-membrane-lib/secure-membrane.js", line 414, in call
| |
| return this.callOrConstruct(wrappee, wrapper, thisObj, args, false);
| |
| File "resource://cuddlefish-jetpack-secure-membrane-lib/secure-membrane.js", line 393, in callOrConstruct
| |
| throw SecureMembrane.wrapTrusted(e);
| |
| File "resource://cuddlefish-jetpack-secure-membrane-lib/secure-membrane.js", line 84, in wrapTrusted
| |
| return this.binary.wrap(thing, new this.TrustedWrapper(thing));
| |
| File "resource://cuddlefish-jetpack-secure-membrane-lib/secure-membrane.js", line 145, in TrustedWrapper
| |
| safeThrow("object has no __exposedProps__!");
| |
| File "resource://cuddlefish-jetpack-secure-membrane-lib/secure-membrane.js", line 2, in safeThrow
| |
| throw SecureMembrane.wrapTrusted(new Error(message));
| |
| File "", line 0, in Error
| |
| Error: object has no __exposedProps__!
| |
| </pre>
| |
|
| |
| '''It looks like the wrong stack actually. The first line (<tt>dump(f.read() + "\n")</tt>) is in the toy feature I've been using to test my capability, and it calls into the capability. I'm sure the error originates inside the capability, but it's not visible here. Is that by design?'''
| |
|
| |
| I think this may indeed be a bug, primarily from looking at the frame coming from line 393 in <tt>callOrConstruct()</tt>; if the thing being thrown from the trusted code one of JS's standard built-in exception types (e.g., <tt>Error</tt>, <tt>ReferenceError</tt>), then the exception should automatically pass through. However, if some special other type of exception is thrown (e.g. a custom exception class, and ''possibly'' an <tt>nsIException</tt>, I'm not sure) then it needs to be given <tt>__exposedProps__</tt> in order to propagate through untrusted code. I guess for exception-based control flow we may want to allow objects to just "pass-through" with no exposed properties, so that this kind of annoyance doesn't occur.
| |
|
| |
| ''adw: Yeah, it's an XPCOM exception. Would it be possible to catch XPCOM exceptions at the boundary, attach an <tt>__exposedProps__</tt> prop, and send them on their way?''
| |
|
| |
|
| '''Any examples for unit-testing my capability?''' | | '''Any examples for unit-testing my capability?''' |