Exceptions that are not caused by the VM should terminate program execution

[jwasinger]

Right now, all exceptions are caught and interpreted as errors within the EVM environment (i.e. out of gas). This causes a myriad of problems.

[kumavis]

yeah this is really annoying
any non-vm error should be considered a catastrophic event and fail immediately

err / vm-err is conflated here https://github.com/ethereumjs/ethereumjs-vm/blob/master/lib/runCode.js#L217
err is lost here https://github.com/ethereumjs/ethereumjs-vm/blob/master/lib/runCall.js#L154-L185

[kumavis]

relevant old issue #117

[holgerd77]

Jared once made the following suggestion when we were chatting on Gitter:

I'm thinking we add special field to mark EVM exceptions.
then in that try/catch
it will look something like this:

try {

} catch (e) {
    if typeof(e) == 'object ' && 'EVMException' in Object.keys(e) {
        OOG Handling...
    }  else {
        throw("real exception, which ends program excecution")
   }
}

@jwasinger: is this still up-to-date or do you have updated ideas on this?

[axic]

#222 is one step towards that (introduces internal_error)

[holgerd77]

@axic I think it would be better to keep the vm errors logically separate from programmatic errors. Any reasons not to settle this on one level higher and introduce a new runState.internalError variable (with some adoptions to post-handling)?

Then one gets also more flexible to store the whole error with the stack trace.

[axic]

@holgerd77 now that #219 is merged it should be easy to change whatever needs to be changed to return INTERNAL_ERROR instead. #222 will introduce internal errors for stack mismatch (if the opcode returns an inconsistent count).

[axic]

I think this should be possible now since we have INTERNAL_ERROR signaling a caught exception.

Maybe that's not the case. @holgerd77 do you want to review runCode and the possible error codes?

[holgerd77]

@axic Yes, can do.

[axic]

Fixed by #307.