我與同事有糾紛。他寫了一個程序，我打電話給一個System.Diagnostics.Process對象並調用process.Start()。但是，在某些情況下，他想拋出一個例外來使自己的過程崩潰，我應該用process.StandardError來解決他的例外，並從那裏處理。如何在進程之間傳遞字符串錯誤消息？
我的直覺反應是這是一個非常糟糕的主意;通過一個未處理的異常終止一個進程是Windows操作系統本身所關注並注意到的事情，像彈出錯誤消息框這樣的東西，這是非常不可取的。我認爲他應該寧願以一些有意義的錯誤代碼優雅地終止，並且我可以檢查該過程的ExitCode。但他說一個整數是不夠的;他想用字符串傳送錯誤信息。
我是否反對讓他拋出異常，崩潰他自己的應用程序？有沒有一種簡單的方法讓他向我傳遞一個字符串錯誤消息，而無需我們在兩個應用程序之間定義特殊的通信機制？你還會推薦什麼？
ExitCode絕對聽起來像一個更好的主意。它更加優雅，並且可以被許多（如果不是全部的話）環境處理。一個ExitCode就是爲了這個目的。
爲了迴應他的聲明ExitCode不足夠：它不是這個意思。 ExitCode應與規範文檔一起使用，詳細說明每個異常代碼 - 原因，修正等。此規格表可以作爲軟拷貝，硬拷貝或僅存在於開發人員的腦海中。
隨着ExitCode，你可以閱讀使用RedirectStandardOutput一些其他的輸出 -
通過啓用它，您`ll能夠讀取進程的stdout \標準錯誤，並通過有關於誤差
一些細節這只是一個想法（工程） - 有可能更好的方法來做到這一點
我假設他的程序是命令行可執行文件。如果他在.net世界中，我會建議使用其他形式的進程間通信命名管道或WCF。或者甚至可能將進程的大部分提取爲dll，並且在自己的進程中調用dll，如果他仍然想要exe，他可以爲此專門創建一個exe前端。
根據我的經驗，'System.Diagnostic.Process'具有很強的特性，在生產中有很多的傾向，我會遠離它。
解析stdin或stderr的錯誤信息更糟。
這裏有良好的線程：
What is the best choice for .NET inter-process communication?
我同意你的直覺。看起來你的同事正在使用一個例外，只是因爲這使得他能夠傳遞信息。這不完全是例外情況... – Treb 2012-03-07 08:03:11