Proposal: Process Exited event fired with process exit type

[hez2010]

Currently a process object Exited event will be fired with parameter object and EventArgs. But we don't know whether the process exited normally or not.

So I hope that the Exited event can attach a property into args which indicated the process exit type(normally exit or abnormally exit).

var a = new Process();
a.Exited += (obj, args) => {
    switch (args.ExitType)
    {
    case ProcessExitType.Normally:
        ....
        break;
    case ProcessExitType.Abnormally
        ....
        break;
    }
}
.....

[stephentoub]

How do you define normal vs abnormal? Why is the Process.ExitCode insufficient? What alternative mechanism do you propose to examine on Windows, macOS, and Linux? Etc.

[hez2010]

@stephentoub Normally exit means a process finished all its work without any unhandled runtime exception, and abnormally means there are some runtime unhandled exception during execution.

If using ExitCode, I can also return a non-zero value in Main function but executing without any unhandled exception.

[stephentoub]

And how do you propose another process determine that?

[hez2010]

@stephentoub Sometimes when starting a process especially when the file is provided by other people, we need to track the process and determine whether the process works fine. If there's any runtime unhandled exception, I can know from ExitType and log it, give some feedbacks or take further actions.

A typical case is Online Judge System.
Users can submit their code and the server will compile it, run, track, collect the resource consuming and read the standard output, and then validate whether the output matches the correct answer. If there's any runtime unhandled exception, we need to feedback to user the judge result is "Runtime Error", and the user need to modify their code to solve the potential bug and submit again.
If we determine the process's exit type by ExitCode, any user wrote "return 1;" (or other non-zero value) in the main function will cause a false positive that the Judge System will report an "Runtime Error" result even there's no unhandled exception occurred actually.

Currently in windows, we can use JobObject and configure it to post a JOB_OBJECT_MSG_ABNORMAL_EXIT_PROCESS signal when the process exited abnormally. But because there's no JobObject supports in .NET Core, determine a process whether exited normally becomes hard and we have to use C++ or declare plenty of P/Invokes about JobObject.
In *unix, we have to use ptrace or other process tracking tools to meet it.

[stephentoub]

If we determine the process's exit type by ExitCode, if any user wrote "return 1;" (or other non-zero value) in the main function, there will be a false positive that the Judge System

How is that different from user code throwing an exception there instead? Your system would still "misinterpret" it.

Exceptions are an implementation detail within a process; some languages don't have them or promote them, and even when one does, developers can choose not to use them. We shouldn't try to teach Process how to determine whether another process exited because it threw exceptions or passed around error codes. That's not a standard part of the contract between a process and operating systems (whereas things like exit code are fairly universal).

I also don't believe we could implement this well or efficiently on all OSes.

[dotnet-policy-service]

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of our issue cleanup automation.

[dotnet-policy-service]

This issue will now be closed since it had been marked no-recent-activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.