|
|
|
|
--- !ditz.rubyforge.org,2008-03-06/issue
|
|
|
|
|
title: set error handler explicitly instead of in every duk_pcall/duk_safe_call?
|
|
|
|
|
desc: |-
|
|
|
|
|
Very often error handler doesn't need to be set (no error handler) and in
|
|
|
|
|
also quite often the existing error handler can be kept (e.g. code uses a
|
|
|
|
|
global error handler). Having an error handler in every protected call is
|
|
|
|
|
a bit inconvenient for the caller.
|
|
|
|
|
|
|
|
|
|
Error handler could be read/written with explicit API calls. The problem
|
|
|
|
|
is that unwinding won't then be automatic and caller must be careful to
|
|
|
|
|
unwind error handler correctly.
|
|
|
|
|
|
|
|
|
|
An intermediate approach would be to have an API call to set the pending
|
|
|
|
|
error handler for the next protected call and the duk_pcall/duk_safe_call
|
|
|
|
|
would pick it up. By default the current error handler would be kept.
|
|
|
|
|
type: :task
|
|
|
|
|
component: duk
|
|
|
|
|
release: v0.10
|
|
|
|
|
reporter: sva <sami.vaarala@iki.fi>
|
|
|
|
|
status: :closed
|
|
|
|
|
disposition: :fixed
|
|
|
|
|
creation_time: 2013-08-06 06:40:20.110056 Z
|
|
|
|
|
references: []
|
|
|
|
|
|
|
|
|
|
id: be47968f8d7c83bad50c40314e61bd2f9beb52e0
|
|
|
|
|
log_events:
|
|
|
|
|
- - 2013-08-06 06:40:20.507034 Z
|
|
|
|
|
- sva <sami.vaarala@iki.fi>
|
|
|
|
|
- created
|
|
|
|
|
- ""
|
|
|
|
|
- - 2013-09-29 10:05:52.754896 Z
|
|
|
|
|
- sva <sami.vaarala@iki.fi>
|
|
|
|
|
- assigned to release v0.8 from v0.7
|
|
|
|
|
- ""
|
|
|
|
|
- - 2013-10-31 00:12:38.098033 Z
|
|
|
|
|
- sva <sami.vaarala@iki.fi>
|
|
|
|
|
- assigned to release v0.9 from v0.8
|
|
|
|
|
- ""
|
|
|
|
|
- - 2014-01-12 13:33:39.442715 Z
|
|
|
|
|
- sva <sami.vaarala@iki.fi>
|
|
|
|
|
- assigned to release v0.10 from v0.9
|
|
|
|
|
- ""
|
|
|
|
|
- - 2014-04-05 13:56:37.797202 Z
|
|
|
|
|
- Sami Vaarala <sami.vaarala@iki.fi>
|
|
|
|
|
- commented
|
|
|
|
|
- |-
|
|
|
|
|
Also one simple model would be to store the current error handler
|
|
|
|
|
in the current Thread object (or perhaps the Thread stash). This
|
|
|
|
|
way it would be reachable regardless of the value stack state, and
|
|
|
|
|
there would be no need for a setjmp catchpoint in the user code to
|
|
|
|
|
restore a previous value.
|
|
|
|
|
|
|
|
|
|
With this approach a module which temporarily sets the error handler
|
|
|
|
|
could fail to restore it afterwards, and an undesired error handler
|
|
|
|
|
would then be effective even after the module returns control to its
|
|
|
|
|
caller. This is probably still better than cluttering all protected
|
|
|
|
|
call related API calls with DUK_INVALID_INDEX arguments (rarely used)
|
|
|
|
|
or using a fragile pending index or something like that.
|
|
|
|
|
- - 2014-04-08 22:38:31.746085 Z
|
|
|
|
|
- Sami Vaarala <sami.vaarala@iki.fi>
|
|
|
|
|
- closed with disposition fixed
|
|
|
|
|
- |-
|
|
|
|
|
Implemented an error handler model based on explicitly set Duktape.errcreate
|
|
|
|
|
and Duktape.errthrow instead.
|
