处理异常和故意执行C＃控制台应用程序的理想方式 [英] Ideal way of handling exceptions and purposely failing execution of C# console application

问题描述

我创建了一个控制台应用程序来执行从 SSIS 包中调用的一些任务。在包中我使用执行进程任务来调用.exe并发送参数。它运行正常。



问题是我正在处理try / catch代码块中的异常。是的，那令人困惑。由于我捕获异常并显示适当的消息，因此应用程序成功结束（返回代码= 0 ），即使发送的错误参数和它没有执行任何操作。我需要程序包来知道应用程序的执行是否失败，以便任务失败并且工作流程将停止。



我所做的是删除try / catch代码，（或者只是在catch部分抛出一个异常），这样任务就会失败，流程就会停止。这让我感到不安。 在这些情况下处理错误的最佳方法是？而不仅仅是从包中调用，而是从外部进程调用应用程序。我知道我可以定义错误代码并退出应用程序

I have created a console application to do some tasks that is to be called from an SSIS package. In the package I use an Execute Process Task to call the .exe and send arguments. It works fine.

The problem is that I'm handling exceptions in try/catch code blocks. Yeah, that's confusing. Since I catch the exception and show the appropiate messages, the application ends succesfully (return code = 0) even if the wrong arguments where sent and it didn't do anything. I need the package to know if the execution of the application failed, so that the task will fail and the work flow will stop.

What I did is remove the try/catch code, (or just threw an exception in the catch part) so that the task will fail and the flow will stop. This disturbs me. What is the best way to handle errors in these situations? And not just a call from a package but any call to the application from an external process. I know I could define error codes and exit the application with

int errorCode = 10; 
Exit(errorCode);

但是，程序包仍然不知道应用程序失败。我查看了 Environment.FailFast（）; 但这似乎与没有做任何事情一样（我错了吗？）。



我不想留下未处理的异常，因为它感觉很脏。我该怎么办？

but, the package still doesn't know that the application failed. I looked into Environment.FailFast(); but that seems to be pretty much the same as not doing anything (am I wrong?).

I don't want to leave exceptions unhandled because it feels dirty. What should I do?

推荐答案

我会因为一般错误而失败，然后将详细的故障信息写入应用程序日志或错误报告文件。



处理异常的最佳做法是仅处理可以对其执行某些操作的异常，其余的则将调用堆栈调用（也就是说，不要捕获它们） ）。您可以在main函数中捕获泛型Exception并返回失败代码（-1）并将详细信息写入日志，这在某种程度上是可以接受的，因为它可以防止其中一个丑陋的Application Terminated Unexpectedly消息。

I would fail with a generic error then write detailed failure info to the application log or an error reporting file.

Best practice for handling exceptions is to only handle exceptions that you can do something about it, the rest you pass up the call stack (aka, don't catch them). You can catch the generic Exception in the main function and return a failure code (-1) and write out detailed information to the log, which is somewhat acceptable since it prevents one of the ugly "Application Terminated Unexpectedly" messages.

除了解决方案1：



处理异常的最终要求是：在每个线程的顶层堆栈帧中捕获它们。面向事件的UI线程有各自的变化：所有异常都应该在线程的主要偶数循环中捕获。通常，UI库在捕获此类异常时会调用特殊事件。



这并不意味着异常可能不会在其他地方被捕获。有时这是不可避免的，但想法是尽可能少地抓住。异常处理的主要特征是与常规代码的隔离。过度捕捉是更常见的错误，然后没有捕捉。我将处理例外的地方称为能力点。阅读Ron的答案，了解它的含义。



最糟糕的问题之一就是在没有做任何事情的情况下捕捉异常（修复重新抛出的问题），阻塞进一步的异常传播这是一个更糟糕的错误，但在极少数情况下需要它。有时应该这样做是为了弥补不良软件库中的一些缺陷，这些软件库没有可用于修补问题的源代码。







关于例外的性质和主要思想，请参阅我过去的答案： C＃构造函数中的异常导致调用者分配失败吗？ [ ^ ]。

-SA

In addition to the Solution 1:

One ultimate requirement to handling exceptions: catch them all on the top stack frame of each thread. Event-oriented UI threads have their own twist: all exceptions should be caught in the main even cycle of the thread. Usually, UI libraries have the special event invoked when such exception caught.

It does not mean that exceptions may not be caught in other places. Sometimes it is unavoidable, but the idea is to catch as little as possible. Main feature of exception handling is the isolation from the "regular" code. The over-catching is much more usual mistake then not catching. I call the places where the exceptions are handled the "points of competence". Read the Ron's answer to understand what it means.

One of the worse problem is catching the exception without doing anything (fixing a problem of re-throwing), which blocks further exception propagation. This is one of the worse mistakes, but there are rare cases where it is needed. This is sometimes should be done to compensate some defects in bad software libraries which don't have source code accessible for patching their problems.



On the nature and main idea of exceptions, please see my past answer: Does Exception in C# Constructor Cause Caller Assignment to Fail?[^].

—SA

这篇关于处理异常和故意执行C＃控制台应用程序的理想方式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！