Open bluenote10 opened 5 years ago
The "quit called" warning is out of place.
I like it and I think quit
is what should be used. It's not out of place since otherwise debugging can be a nightmare. (How do I know? We used to lack this hint and the compiler would "die" and we didn't know why nor how nor where.)
Agreed logging quit
calls in the compiler makes sense, but for NimScript / Nimble there are use cases to exit gracefully without a message:
Supporting return <int>
for Nimble tasks would achieve silent exists without the need to explicitly kill the script.
Given nimble now just calls nim e
behind the scenes, quit(1) now behaves differently.
raise newException()
=>
> nimble one --verbose
Reading config file at ~/.config/nimble/nimble.ini
Executing task one in ~/programming/a/a.nimble
stack trace: (most recent call last)
/tmp/nimblecache/nimscriptapi.nim(164, 16)
~/programming/a/a_15029.nims(21, 3) oneTask
~/programming/a/a_15029.nims(21, 3) Error: unhandled exception: Exception text
Error: ~/programming/nimbledevel/src/nimble.nim(1145) nimble
... ~/programming/nimbledevel/src/nimble.nim(1129) doAction
... ~/programming/nimbledevel/src/nimblepkg/nimscriptexecutor.nim(46) execCustom
... ~/programming/nimbledevel/src/nimblepkg/nimscriptwrapper.nim(164) execTask
... ~/programming/nimbledevel/src/nimblepkg/nimscriptwrapper.nim(135) execScript
... Exception raised during nimble script execution
quit(1)
=>
> nimble one --verbose
Reading config file at ~/.config/nimble/nimble.ini
Executing task one in ~/programming/a/a.nimble
Error: ~/programming/nimbledevel/src/nimble.nim(1145) nimble
... ~/programming/nimbledevel/src/nimble.nim(1129) doAction
... ~/programming/nimbledevel/src/nimblepkg/nimscriptexecutor.nim(46) execCustom
... ~/programming/nimbledevel/src/nimblepkg/nimscriptwrapper.nim(164) execTask
... ~/programming/nimbledevel/src/nimbl
It seems quit(1)
was broken, that sucks.
I actually disallow quit
in Nimble's source code for the untraceability reason too and instead offer a NimbleQuit
exception so you can always find which code wanted to quit. Personally I would like the same thing for the task API. What I really think we should do is create an RFC outlining precisely the API that the task API should have. I'm going to start the conversation in another issue.
Currently the task API doesn't seem to support exit codes. If a task encounters an error it can:
return
: this will abort, but the exit code of runningnimble myTask
will be 0.quit(exitCode)
: Sets a non-zero exit code, but for some reason Nimble seems to issue a warning "quit called". This warning doesn't make sense from a user perspective, because the task has already printed a meaningful error message and simply wants to abort. The "quit called" warning is out of place.Maybe the task API could be extended so that it supports
return <int>
and Nimble forwards the code directly toquit
without injecting a warning?