Return non-zero exit code for unhandled exceptions

[Bouke]

✨ What kind of change does this PR introduce? (Bug fix, feature, docs update...)

feature

⤵️ What is the current behavior?

Currently when an exception is thrown besides CommandParsingException, the exit code of the tool will be 0 (no error). This means that in CI builds on a schedule, you won't get build failures if something is wrong (#904).

C:\Program Files\dotnet\dotnet.exe (process 13168) exited with code 0.

🆕 What is the new behavior (if this is a feature change)?

With this change, a non-zero exit code is returned, which would then fail the build and cause alarm bells to ring.

C:\Program Files\dotnet\dotnet.exe (process 13168) exited with code 2.

💥 Does this PR introduce a breaking change?

Maybe. So other tools relying on a zero exit code even when errors happen, would need a change. I think this is desirable.

🐛 Recommendations for testing

Nuget.config:

@@ -0,0 +1,9 @@
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <clear/>
  </packageSources>
</configuration>

📝 Links to relevant issues/docs

#904

🤔 Checklist before submitting

• All projects build
• Relevant documentation was updated

[MarcBruins]

Mm the returning of a code other then 0 is definitely a good idea. I don't like the enum status codes and the additional cast that comes with it though. Can't we just return the integer value?

[Bouke]

The reason for using enums is to be clear about which error codes can be returned, and a single location of defining those return codes. Using different error codes allows scripts to behave differently depending on the error code, log error code etc. The MVP here would be to return non-zero on errors, so dropping the enum is fine by me.