You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 
 

64 lines
2.5 KiB

--- !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.