issue-39aedeea300bb4c85d94d18ea3f031b24c199100.yaml

--- !ditz.rubyforge.org,2008-03-06/issue 
title: unify panic and fatal error handling
desc: ""
type: :task
component: duk
release: v0.10
reporter: sva <sami.vaarala@iki.fi>
status: :closed
disposition: :wontfix
creation_time: 2013-08-04 20:35:19.670686 Z
references: []

id: 39aedeea300bb4c85d94d18ea3f031b24c199100
log_events: 
- - 2013-08-04 20:35:20.027511 Z
  - sva <sami.vaarala@iki.fi>
  - created
  - ""
- - 2013-09-29 10:05:52.514695 Z
  - sva <sami.vaarala@iki.fi>
  - assigned to release v0.8 from v0.7
  - ""
- - 2013-10-31 00:12:37.899950 Z
  - sva <sami.vaarala@iki.fi>
  - assigned to release v0.9 from v0.8
  - ""
- - 2014-01-12 13:33:38.870272 Z
  - sva <sami.vaarala@iki.fi>
  - assigned to release v0.10 from v0.9
  - ""
- - 2014-02-02 22:06:46.086621 Z
  - sva <sami.vaarala@iki.fi>
  - changed status from unstarted to in_progress
  - |-
    All places using DUK_PANIC() could actually use a DUK_FATAL(heap) instead,
    except for assertions.
    
    Perhaps keep DUK_PANIC() only for assertions and convert everything else to
    use DUK_FATAL().  That way the release build would never use the panic
    mechanism, simplifying public API.  Assertions could also be converted to
    always take a heap reference, but this would be quite tedious.
- - 2014-02-03 23:36:20.195944 Z
  - sva <sami.vaarala@iki.fi>
  - commented
  - |-
    Changed so that DUK_PANIC() is only used by assertions and the default
    fatal error handler.  The only reason Duktape throws fatal errors now
    is for uncaught errors.
    
    If the user defines a fatal error handler and runs a non-assertion
    build, DUK_PANIC() never gets called.
- - 2014-02-03 23:36:26.299776 Z
  - sva <sami.vaarala@iki.fi>
  - closed with disposition wontfix
  - ""