[API Proposal]: Process.TryGetProcessById()

[mqudsi]

Background and motivation

The existing api for retrieving a process by its process id (Process.GetProcessById()) does not provide any exception-safe method of querying a process, as it throws an ArgumentException if the specified pid cannot be found and there is no means of atomically guaranteeing that a once-valid process id will remain valid by the time the Process.GetProcessById() call is being serviced.

This is true regardless of where the pid was obtained from, even if the pid were obtained from a previous call to Process.GetProcessById() due to the inherently concurrent execution model associated with multiprocessing.

If it's any sort of additional incentive, the exception thrown by Process.GetProcessById() when a valid-but-no-longer-extant pid is provided is ArgumentException, which is normally not an exception that a calling library/application should be catching. Moreover, the reuse of ArgumentException to indicate both "process not found" and "invalid machine name" (for the two-parameter override) adds to the confusion of using this api, as one case is intended to be caught and the other, generally speaking, is not.

API Proposal

namespace System.Diagnostics;

public class Process
{
 // we already have Process.GetProcessById(processId
 public static bool TryGetProcessById(int processId, [NotNullWhen(true)] out Process process);
 // overload with machineName is not included on purpose: it's Windows-specific
}

namespace Microsoft.Win32.SafeHandles;

public SafeProcessHandle
{
 // we already have SafeProcessHandle.Open
 public static bool TryOpen(int processId, [NotNullWhen(true)] out SafeProcessHandle? processHandle);
}

API Usage

if (Process.TryGetProcessById(pid, out Process process))
{
 process.Kill()
}

Risks

Some might be concerned about the proliferation of TryFoo() methods, though working around the unfortunate legacy use of ArgumentException here and the inherently fallible nature of obtaining a process (that may have already exited) by its id really lend themselves to recommending the addition of an exception-free alternative to the current Process.GetProcessById() method.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-diagnostics-process
See info in area-owners.md if you want to be subscribed.

[daniel-white]

The Try... pattern usually has an out parameter and return a Boolean. I would expect this api to work the same way

[stephentoub]

Can you elaborate on the scenario where this is needed? You're on some path where the overhead of the exception is prohibitive?

[tannergooding]

I don't think that Try* APIs should be restricted to just cases where exception overhead is prohibitive or performance sensitive areas.

Exceptions are massively expensive, they can be error prone to handle, may not actually cover what the user wanted to cover over time, and it is generally considered best practice to not do control flow based on exceptions. Forcing users to handle them in scenarios that are known to be prone to arbitrary failure (looking up process IDs, opening or creating files, etc) just because the operation itself already has a larger bit of overhead doesn't make sense to me and seems to be encouraging practices that are widely touted as being bad or problematic.

The general try { } catch (...) { } pattern is also tricky for many different reasons and can be difficult to integrate into general control flow paths. A user can always define their own helper TryGetProcessId path that itself does the try/catch and converts the exception to bool, but that's a lot more complex and really inverts the more normal expectation (which is simply exposing it ourselves such that GetProcessId calls TryGetProcessId and throw if it returns false; and therefore achieves the same thing but in a stable/documented way that also gives it to the user as cheaply as possible and without any significant overhead required on our part).

[stephentoub]

I don't think that Try* APIs should be restricted to just cases where exception overhead is prohibitive or performance sensitive areas.

That's an extremely slippery slope. .NET uses exceptions for these cases. From my perspective, that argument effectively leads to saying that any method which could throw (which is many) could have a Try method just to represent failure differently, and that's not a path we're going to go down.

[danmoseley]

I've seen this discussion a few times on API proposals in the past and generally they returned to the consensus that .NET for good or ill chose the exception model for error handling and the Try pattern is only for the highest performance cases where errors are inevitable e.g. parsing.

If we use the Try pattern more broadly, what criteria do you believe we should use to decide whether it is worthwhile to add the duplicate API?

[daniel-white]

For this theres a cost even in determining whether the process exists or not. Looking at the implementation its using kill on *ix, so would the cost for an exception be still higher? perhaps a helper method to see if the process is still alive then attempt to use GetProcessById after might be better? then again theres a race. this could be easily implemented by the caller.

[tannergooding]

That's an extremely slippery slope. .NET uses exceptions for these cases. From my perspective, that argument effectively leads to saying that any method which could throw (which is many) could have a Try method just to represent failure differently, and that's not a path we're going to go down.

I disagree. This isn't a statement that try can/should be provided for "any method" which could throw, it's specifically keeping the spirit of Try* APIs as detailed in the FDG

CONSIDER the Try Pattern for members that might throw exceptions in common scenarios to avoid performance problems related to exceptions.

The only difference is that it's saying that "to avoid performance problems related to exceptions" should be extended to basically include something along the lines of "or where the user performing their own pre-validation is impossible".

So something like TimeSpan.FromHours should not have some TimeSpan.TryFromHours, this doesn't make sense. A user can trivially validate it themselves before hand and has many avenues for avoiding the exception.

However, something like Process.GetProcessId or File.Delete are cases where there is literally nothing a user can do except for catch the exception that is currently being thrown. This is because they are explicitly interacting with systems outside the control of the process which may be getting changed concurrently. It's the same reason why if (File.Exists(...) { File.Delete(...); } is problematic and why issues like #27217 have been opened.

There is a very clear and distinguished line we can draw that keeps this from being a slippery slope. Which provides clear and concise benefit to users that are using these APIs while maintaining the spirit of the guideline and how users generally expect Try APIs to work.

[tannergooding]

We are ourselves functionally using system level "try apis" for most of the functions in this category already and simply converting them to exceptions 100% of the time.

So it's really just an ask to expose the functionality the system already provides because the system already understands that it needs to exist that way.

[stephentoub]

The only difference is that it's saying that "to avoid performance problems related to exceptions" should be extended to basically include something along the lines of "or where the user performing their own pre-validation is impossible".

And I believe that extension includes the vast majority of exceptions we end up throwing.

it's specifically keeping the spirit of Try* APIs as detailed in the FDG

I disagree. That "or" is a very large leap from the original spirit.

[tannergooding]

And I believe that extension includes the vast majority of exceptions we end up throwing.

Do you have an example of what you think it would include?

The things people have historically asked for these APIs around are explicitly APIs like file handling or things involving processes and that other languages and the system APIs themselves provide "try" like APIs for.

It feels like a disservice to .NET users to keep pushing off exposing such functionality ourselves due to the potential for it to be a slipper slope or belief that the performance characteristics don't matter.