issue-be47968f8d7c83bad50c40314e61bd2f9beb52e0.yaml

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