Find a way to handle scenarios when application should exit with error, but not stacktrace.

[AdmiringWorm]

Few quick thought I have for handling these scenarios (not really a fan of either one, but just putting them out here in case).

• Using Environment.Exit to quickly exit the program (Could result in a too complicated flow of the program though).
• Having a separate class/interface that allows setting the exit code (but will still continues execution).
• Using custom exception classes (with a final try/catch block in the program that won't rethrow if that exception class is used, only write the error message and exit).
• Using events to handle the exit (same problem as the first one though).
• Returning an execution state enum from all api related methods.

As I said, not a fan of any of those, but those are the ones I can think of right now.

[gep13]

@AdmiringWorm in the past, I have done the last item on the list, but it also included a collection of errors that occurred, as there can be more than one. I think whatever we do, we should account for the following issue as well: https://github.com/GitTools/GitReleaseManager/issues/113

[AdmiringWorm]

Probably, but I am honestly not following exactly what he is asking for in that issue. But I think I get the gist of it.

[AdmiringWorm]

I have done the last item on the list, but it also included a collection of errors that occurred, as there can be more than one

I have never really done that, what I have done in the past (out of the things I mentioned) is to have nested custom classes, this way I could recursively output all nested exceptions, and if the user passed in --verbose/--debug I could output the stacktrace as well.

[AdmiringWorm]

This could actually be fixed by implementing logger for Serilog.

Only output stacktrace if using a debug verbosity.

[gep13]

@AdmiringWorm I am going to suggest that we bump this to a future milestone, would be great to have, but there will be a few moving parts here.