我与同事发生争执。他编写了一个程序，我正在使用System.Diagnostics.Process对象调用并调用process.Start()。但是，在某些情况下，他想抛出一个异常来破坏他自己的进程，我应该使用process.StandardError捕获他的异常并从那里处理它。
我的直觉反应是，这是一个非常糟糕的主意;通过未处理的异常终止进程是Windows操作系统自身所处理并注意到的事情，例如弹出错误消息框，这是非常不受欢迎的。我认为他应该优雅地使用一些有意义的错误代码终止，我可以检查进程的ExitCode。但他说整数是不够的;他希望以字符串形式传输错误消息。
我是否反对让他抛出异常，崩溃他自己的应用程序？有没有简单的方法让他传递一个字符串错误消息，而我们不必在两个应用程序之间定义一个特殊的通信机制？你还推荐什么？
答案 0 :(得分：3)
ExitCode肯定听起来更好。它更加优雅，可以通过众多（如果不是全部）呼叫环境来处理。 ExitCode就是为了这个目的。
回应他的声明，即ExitCode是不够的：它并不意味着。 ExitCode应该与详细说明每个异常代码的规范文档一起使用 - 原因，修复等。此规格表可以作为软拷贝，硬拷贝或仅仅在开发人员的脑海中存在。
答案 1 :(得分：2)
与ExitCode一起，您可以使用RedirectStandardOutput -
读取其他一些输出通过启用它，您将能够读取进程的stdout \ stderr，并由此获得有关错误的更多详细信息
这只是一个想法（有效） - 可能有更好的方法来做到这一点
答案 2 :(得分：1)
我认为他的程序是命令行可执行文件。如果他在.net世界，我建议使用其他形式的进程间通信命名管道或WCF。或者甚至可以将进程的大部分提取到dll中，并让你在自己的进程中调用dll，如果他仍然需要exe，他可以专门为此创建一个exe前端。
根据我的经验，'System.Diagnostic.Process'具有很强的特性和生产中的大量惊喜，我会远离它。
解析stdin或stderr的错误消息更糟糕。
这里有好的主题：
What is the best choice for .NET inter-process communication?