search

inim-repl / INim

Interactive Nim shell / REPL / Playground
MIT License
644 stars 23 forks source link

Handling `sysFatal` gracefully #128

Open adigitoleo opened 2 years ago

adigitoleo commented 2 years ago

Unhandled sysFatal from top level scope can crash the repl:

%zsh> inim
👑 INim 0.6.1
Nim Compiler Version 1.6.0 [Linux: amd64] at /usr/bin/nim
nim> var s = newSeq[int](5)
nim> s[5] = 42
fatal.nim(53)            sysFatal
Error: unhandled exception: value out of range: -1 notin 0 .. 9223372036854775807 [RangeDefect]

Other unhandled sysFatal don't show the error message:

%zsh> inim
👑 INim 0.6.1
Nim Compiler Version 1.6.0 [Linux: amd64] at /usr/bin/nim
nim> proc oof() =
....   var s = newSeq[int](5)
....   s[5] = 42
....
nim> oof()
/usr/lib/nim/lib/system/fatal.nim(53) sysFatal
0atman commented 2 years ago

confirmed, these should not crash the repl, ideally. Perhaps they should be removed from execution so that further commands can continue?

adigitoleo commented 2 years ago

Looks like the crash isn't happening any more with nim 1.6.6, the message is still missing in the second case however.

adigitoleo commented 2 years ago

Crash is back, either I was talking nonsense before or it is reintroduced. My naive idea for this was to somehow catch sysFatal during the internal compile cycle (although I understand that it's more like a panic than an exception), but that requires a better understanding of fatal.nim than I have: https://github.com/nim-lang/Nim/blob/devel/lib/system/fatal.nim

In particular, Nim is not always simply raiseing something, there's a few platform/compiler-flag specific behaviours.

adigitoleo commented 4 months ago

On INim v1 with nim v2.0.8 (linux amd64) neither of these are crashing anymore. The first case no longer throws sysFatal. The second does, but it is not crashing the REPL anymore. If you can confirm that there is no crash on Windows either then this can probably be closed.