我与同事有纠纷。他写了一个程序，我打电话给一个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