-
Notifications
You must be signed in to change notification settings - Fork 18
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Updated `validate` to work with `toUserLand` to propagate exceptions thrown bu the user, so that user thrown exceptions are not caught and fed to the user callback as Strata errors. Created a `toUserLand` function that will mark an exception thrown by the user callback as such, so that it is not caught by `validate` and fed back to the user callback. The user land exception is assigned to the `thrownByUser` variable. As the stack unwinds, if a `validate` function catch the exception, it will check to see if it is the same as the `thrownByUser` function. If it is, it will rethrow the exception. Note that this means we hold onto the last user exception thrown until the next user exception is thrown. There's no way of knowing how deeply nested we are in `validate` callbacks, so we can't clear it as part of the unwind. We clean it up periodically by clearing `thrownByUser` in calls to `cursor`, which ought to get called often enough to ensure that the memory is freed. Also, we clear in `close`, in case that's the last we hear from the user for a while. I can't imagine the trickery the user would employ to make a delayed collection of a thrown error cause problems for his program. Be warned that errors thrown through Strata are going to be held by Strata for some time. The alternative would be to set a flag on the error. No garbage collection issues, but that's even more obtrusive. I'd prefer to be less obtrusive, but holding onto an exception is not entirely unobtrusive. It's not perfectly unobtrusive. I am not afraid that this is going to cause problems for users, or that anyone is going to accuse me of leaking memory. It's theoretically obtrusive, but practically unobtrusive. The only case that occurs to me is in ES6 where the user may be tracking the exception using a `WeakMap` and counting on the disappearance of the exception in the map to mean something. Except that I've had a look, if the user does not hold a reference to the `Error`, he can't look in his `WeakMap` for an error. Thus, deterministic and unobtrusive. Thanks for listening. Closes #174. Closes #173.
- Loading branch information
1 parent
87fccc1
commit 2912e87
Showing
2 changed files
with
81 additions
and
17 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,22 @@ | ||
require("./proof")(1, function (step, Strata, equal, tmp) { | ||
var strata; | ||
step(function () { | ||
|
||
strata = new Strata({ directory: tmp, leafSize: 3, branchSize: 3 }); | ||
strata.create(step()); | ||
|
||
}, function () { | ||
|
||
try { | ||
strata.iterator('a', function (error, cursor) { | ||
cursor.unlock() | ||
throw new Error('propagated') | ||
}) | ||
} catch (e) { | ||
equal(e.message, 'propagated', 'propagated error') | ||
|
||
strata.close(step()) | ||
} | ||
|
||
}); | ||
}); |