fix #1994 gorge, staticExec now raise Assert on exitCode !=0; simplified implementation

[timotheecour]

• fix Can't tell return value of programs with staticExec #1994

[dom96]

Thanks for working on this!

[dom96]

Assertions aren't catchable, I think we want something that is catchable to be raised.

[timotheecour]

but that's at compile time; user can always use the cleaner gorgeEx variant which returns exitCode and handle accordingly so there's 0 loss of functionality.

In any case, catching doesn't work:

static:
  try:
    let a = gorge("D20190116T211842")
  except OSError as e:
    echo "caught"

gives:

Error: cannot evaluate at compile time: currException

[krux02]

You should not just break the compatibility with existing code that uses the existing API. Please find a deprecation path that doesn't break existing code.

[krux02]

one possible solution is like in bash, it the exit code always in a special variable, but that is bad in multithreaded environments.

You should rename the title of this review. With the title how it is now I wanted to close this PR without even looking at the code, because an assert would break my usages of staticExec.

[timotheecour]

You should not just break the compatibility with existing code that uses the existing API. Please find a deprecation path that doesn't break existing code.

discussed in #10360

one possible solution is like in bash, it the exit code always in a special variable, but that is bad in multithreaded environments.

that's too error prone. Note also that this is all compile time.

You should rename the title of this review. With the title how it is now I wanted to close this PR without even looking at the code, because an assert would break my usages of staticExec.

a PR shouldn't be closed just because there's 1 thing you dislike about it in the title, especially when that thing can be addressed/fixed during review.

If you have a concrete way to raise an exception that can be caught, please explain (after having tested it to work): as I've explained above, if I call raise newException(OSError) instead of calling doAssert, attempt at catching it results in Error: cannot evaluate at compile time: currException (see #10345 (comment))

• I'm hitting a technical wall with this approach, which is the test failure for ./tests/vm/tgorge.nim gorgehas the odd (and undocumented) behavior of settingworkingDirtofooifgorgeis called fromfoo/bar.nim; I couldn't figure out how to keep that behavior with approach in this PR that makes gorgea regular proc callinggorgeEx, because: if gorgeis a regular proc, we have no knowledge (at CT) of caller; ifgorgeis made a template (and usinginstantiationInfo`), it also leads to other issues that I cannot solve (without changing the compiler).

because of that, I'm closing this in favor of #10360 but if someone has a concrete idea (and has tested it to work!) for how to make it work, please let me know and I'll reopen this PR as it's cleaner in some ways