{"id":112351,"date":"2026-05-25T07:00:00","date_gmt":"2026-05-25T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=112351"},"modified":"2026-05-25T21:46:33","modified_gmt":"2026-05-26T04:46:33","slug":"20260525-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20260525-00\/?p=112351","title":{"rendered":"A hypothetical redesign of System.Diagnostics.Process<\/CODE> to avoid confusion over properties that are valid only when you are the one who called Start<\/CODE>"},"content":{"rendered":"

Some time ago, I noted that the Process.Standard\u00adOutput<\/code> property is an attractive nuisance<\/a> because it is valid only on Process<\/code> objects that you called Start<\/code> on. You can’t just grab any old Process<\/code> object and try to access its standard handles.<\/p>\n

Others in the comments had their ideas on how to remove the confusion. Here’s mine. The principle is that the properties and methods of the Process<\/code> object should be valid for all instances of the Process<\/code> class. If a property or method is valid only conditionally, then either move it to a place that is accessible only if the condition is met, or get rid of it entirely if it adds no value.<\/p>\n

The standard handles are the three properties that make sense only for Process<\/code> objects that were created by the static Start<\/code> method. There are also four methods related to those standard handles, as well as two events. Move them all to a new class, call it Process\u00adStart\u00adResult<\/code>:<\/p>\n

class ProcessStartResult\r\n{\r\n    public Process Process { get; }\r\n    public System.IO.StreamWriter StandardInput { get; }\r\n    public System.IO.StreamWriter StandardOutput { get; }\r\n    public System.IO.StreamWriter StandardError { get; }\r\n\r\n    public void BeginOutputReadLine();\r\n    public void CancelOutputReadLine();\r\n    public event DataReceivedEventHandler? OutputDataReceived;\r\n\r\n    public void BeginErrorReadLine();\r\n    public void CancelErrorReadLine();\r\n    public event DataReceivedEventHandler? ErrorDataReceived;\r\n}\r\n<\/pre>\n
Change the signature of all the overloads of the Start<\/code> method so that they return a Process\u00adStart\u00adResult<\/code> instead of a Process<\/code>. Now it is impossible to do anything with the standard handles from a process you didn’t start: If you didn’t start the process, then you don’t have a Process\u00adStart\u00adResult<\/code>. This removes the confusion that existed in the original attempt to have a process read from its own standard output.<\/p>\n
This follows  a principle I wrote about earlier<\/a>: To force the developer to do things in a certain order, make the second step dependent on something produced by the first step. In this case, we want to force the developer to call Start<\/code> before they use the standard handles, so we put the members related to the standard handles on a thing that you can obtain only by calling Start<\/code>.<\/p>\n
Next, remove the Start\u00adInfo<\/code> property entirely. It serves two purposes:<\/p>\n