Fatal error / exception handling #10
Conversation
mikee47
force-pushed
the
feature/fatal-error-handling
branch
from
ad9869f
to
aadd60e
Compare
mikee47
force-pushed
the
feature/fatal-error-handling
branch
from
aadd60e
to
c5f6aa4
Compare
Some additional revisions which should be considered before release. **fixes** - Update 'load' and 'eval' functions, they return a value, not bool - Tidy up `Object::getFunction` to return only requested function or error - Fix Value move constructor / assignment operator, reset() - Fix `Value::isEmpty()` and String() operator - Prevent `Null`, `Undefined` from being constructed with different values. - Must not use internal jerryscript headers publicly. Can introduce invalid #defines. **improvements** - Enable snapshot compiler error messages. e.g. shows position of syntax errors in .js - Update Advanced_Jsvm README. Remove diagram, etc. which is in main library README, and re-word appropriately. - Add JERRY_ERROR_MESSAGES variable, optionally include library messages - Generate type maps from jerryscript headers. Avoids manual copying of values which may change in future releases. - Add feature test, i.e. JS::isFeatureEnabled() - Only enable JERRY_ENABLE_DEBUG explicitly; should only be required for jerryscript library debugging. - Additional tests. - Enable parser support via `JERRY_PARSER` variable - `eval()` won't work without this. Known issues; - For esp8266, constant data cannot be easily moved to flash as accesses are not always word aligned. This will be more involved and handled as a separate PR. - Fatal errors are not handled and will cause system reset. See #10. - Whilst `eval()` will work with parser support enabled, the main parse/run interfaces are more extensive and have not yet been ported.
mikee47
force-pushed
the
feature/fatal-error-handling
branch
from
c5f6aa4
to
79ef355
Compare
Use Except object for nestable exception handling. Add fatal test module
mikee47
force-pushed
the
feature/fatal-error-handling
branch
from
79ef355
to
bf47726
Compare
|
@slaff Tried a few approaches to this and think this is the way to go. Thoughts? |
@mikee47 I like this PR the way it is. If you have some additional work to polish this PR - can you do it so that I can merge this PR and have these changes also in Sming v4.5.0 ? |
mikee47
force-pushed
the
feature/fatal-error-handling
branch
from
bf47726
to
07b4e48
Compare
| JS::Object event; | ||
| event["name"] = name; | ||
| event["params"] = params; | ||
| JS_TRY() |
There was a problem hiding this comment.
@mikee47 I am wondering isn't it possible to use try-catch directly in the JavaScript code and catch out-of-memory exception? We could expose a reset() JavaScript function that resets the VM and give the JS developers (end user) better control. On the C/C++ side we could check if the VM is in error state and restart the VM automatically if it stays in this error state for 8 seconds.
There was a problem hiding this comment.
Unfortunately fatal errors are not the same as javascript exceptions and cannot be caught in script. The engine is essentially halted. No attempt to even tidy up intermediate allocations so cleanup won't work. Try running the tests with JERRY_ENABLE_DEBUG=1 and see what happens!
A reset() function would be very easy to implement. However, depending on the use-case if we wanted multiple clients runninng together would we really want one of them to be able to pull the rug out from the others? Maybe, but that'll depend on usage.
It's going to get confused with external contexts.
mikee47
force-pushed
the
feature/fatal-error-handling
branch
2 times, most recently
from
4f364aa
to
651d12a
Compare
mikee47
force-pushed
the
feature/fatal-error-handling
branch
from
651d12a
to
17378eb
Compare
mikee47
force-pushed
the
feature/fatal-error-handling
branch
from
17378eb
to
f092264
Compare
The goal of this PR is to be really horrible to jerryscript and do nasty things in javascript to see what breaks.
First thing is to allocate large array and see what happens.
We get a fatal 'out of memory' exception which trips 'jerry_port_fatal
. As this is a no-return function, I've used setjmp/longjmp to catch these failures incall`, which works.BUT. How to indicate this to the caller? In general, we cannot rely on the state of jerryscript after a fatal error so it must be re-initialised. That requires application co-operation.
The solution proposed here implements a simple exception handling mechanism using setjmp/longjmp.
Two macros,
JS_TRY()andJS_CATCH()could be re-implemented using regular C++ exception handling if required.The handler has to go at the top execution level. I've revised the
Event_Jsvmsample to demonstrate how this works.Note: Enabling jerryscript assertions makes recovery impossible in some situations, so clearly that's only intended for debugging jerryscript itself.