完全在 try/catch 内部的主要方法代码:这是不好的做法吗?

本文介绍了完全在 try/catch 内部的主要方法代码:这是不好的做法吗?的处理方法,对大家解决问题具有一定的参考价值

问题描述

通常我将所有 Main 方法代码放在 try/catch 块中,如下所示:

Usually I put all of my Main method code inside of a try/catch block like so:

public static void Main(string[] args)
{
   try
   {
      // code
   }
   catch (Exception e)
   {
      // code
   }
}

我这样做只是为了防止任何异常设法从程序逻辑的其余部分中溜走,从而允许我做一些事情,例如将其显示到控制台,将其记录到文件等.但是,我被告知这是不好的做法.

I do this just in case any exceptions manage to slip out of the rest of the program logic, thus allowing me to do something about it, such as display it to console, log it to a file, etc. However, I have been told that this is bad practice.

你认为这是不好的做法吗?

Do you think it is bad practice?

推荐答案

try/catch任何段代码> 没有正当理由的阻止是不好的做法.

在 .NET 编程模型中,应为真正的异常情况或条件保留异常.您应该尝试捕获您实际上可以做某事的异常.此外,您应该几乎永远捕获基本的 System.Exception 类(而是更喜欢捕获您可以的更具体的派生异常类)处理).如果在您的程序执行过程中遇到真正意外的异常,您实际上应该崩溃.

In the .NET programming model, exceptions should be reserved for truly exceptional cases or conditions. You should only try to catch exceptions that you can actually do something about. Furthermore, you should should hardly ever catch the base System.Exception class (but rather prefer to catch the more specific, derived exception classes you can handle). And should a truly unexpected exception be encountered during the course of your program's execution, you actually should crash.

显然,正确"的答案必须逐案确定,具体取决于 //code 占位符中的 catch> 阻止.但是,如果您要的是一般规则或最佳实践",那么您应该始终有一个特定的理由来捕获异常,而不仅仅是将所有代码包装在一个巨大的 try/catch 中 不假思索地把块当作理所当然.

Obviously the "correct" answer would have to be made on a case-by-case basis, depending on what's going on inside that // code placeholder in your catch block. But if you're asking for a general rule or "best practice", you should always have a specific reason to catch exceptions, not just wrap all of your code in a giant try/catch block as a matter of course without thinking about it.

请注意,如果您只是为了记录或错误报告而试图捕获任何可能发生的未处理的异常,您应该使用 AppDomain.UnhandledException 事件.这是一个仅通知事件,因此它不允许您处理这些异常,但它是在应用程序崩溃后实现日志记录或错误报告功能的正确位置.

Note that if you're simply trying to catch any unhandled exceptions that might occur for the purposes of logging or error reporting, you should be using the AppDomain.UnhandledException event. This is a notification-only event, so it doesn't allow you to handle those exceptions, but it is the right place to implement your logging or error reporting functionality after your application has crashed.

当我正在阅读 Raymond Chen 的优秀博客时,"The Old New Thing",我注意到他最近发表了一篇关于类似主题的文章.它特定于 COM,而不是 .NET Framework,但有关错误处理的一般概念同样适用于这两种环境.我想我会在这里分享这篇文章中的一些精华,以支持我的 [显然颇有争议] 的观点.

As I was catching up on my reading of Raymond Chen's excellent blog, "The Old New Thing", I noticed that he had recently published an article on a similar topic. It's specific to COM, rather than the .NET Framework, but the general concepts regarding error handling are equally applicable to both environments. I thought I'd share a couple of gems from the article here, in support of my [apparently quite controversial] opinion.

从历史上看,COM 在服务器的方法周围放置了一个巨大的 try/except.如果您的服务器遇到通常未处理的异常,巨大的 try/except 会捕获它并将其转换为错误 RPC_E_SERVERFAULT.然后它将异常标记为已处理,以便服务器保持运行,从而即使在遇到问题时也保持服务器运行来提高健壮性."

Historically, COM placed a giant try/except around your server's methods. If your server encountered what would normally be an unhandled exception, the giant try/except would catch it and turn it into the error RPC_E_SERVERFAULT. It then marked the exception as handled, so that the server remained running, thereby "improving robustness by keeping the server running even when it encountered a problem."

请注意,这实际上是一种伤害.

Mind you, this was actually a disservice.

发生未处理异常的事实意味着服务器处于意外状态.通过捕获异常并说别担心,一切都很好",您最终会使损坏的服务器继续运行.

The fact that an unhandled exception occurred means that the server was in an unexpected state. By catching the exception and saying, "Don't worry, it's all good," you end up leaving a corrupted server running.

[ ...]

捕获所有异常并让进程继续运行假定服务器可以从意外故障中恢复.但这是荒谬的.您已经知道服务器不可恢复地吐司:它崩溃了!

Catching all exceptions and letting the process continue running assumes that a server can recover from an unexpected failure. But this is absurd. You already know that the server is unrecoverably toast: It crashed!

最好让服务器崩溃,以便可以在故障点捕获崩溃转储.现在您有机会弄清楚发生了什么.

Much better is to let the server crash so that the crash dump can be captured at the point of the failure. Now you have a fighting chance of figuring out what's going on.

您可以 [并且应该] 在他的博客上阅读整篇文章:如何关闭 COM帮助"环绕您的服务器的异常处理程序.

You can [and should] read the whole article here on his blog: How to turn off the exception handler that COM "helpfully" wraps around your server.

这篇关于完全在 try/catch 内部的主要方法代码:这是不好的做法吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,WP2

admin_action_{$_REQUEST[‘action’]}

do_action( "admin_action_{$_REQUEST[‘action’]}" )动作钩子::在发送“Action”请求变量时激发。Action Hook: Fires when an ‘action’ request variable is sent.目录锚点:#说明#源码说明(Description)钩子名称的动态部分$_REQUEST['action']引用从GET或POST请求派生的操作。源码(Source)更新版本源码位置使用被使用2.6.0 wp-admin/admin.php:...

日期:2020-09-02 17:44:16 浏览:1127

admin_footer-{$GLOBALS[‘hook_suffix’]}

do_action( "admin_footer-{$GLOBALS[‘hook_suffix’]}", string $hook_suffix )操作挂钩:在默认页脚脚本之后打印脚本或数据。Action Hook: Print scripts or data after the default footer scripts.目录锚点:#说明#参数#源码说明(Description)钩子名的动态部分,$GLOBALS['hook_suffix']引用当前页的全局钩子后缀。参数(Parameters)参数类...

日期:2020-09-02 17:44:20 浏览:1032

customize_save_{$this->id_data[‘base’]}

do_action( "customize_save_{$this->id_data[‘base’]}", WP_Customize_Setting $this )动作钩子::在调用WP_Customize_Setting::save()方法时激发。Action Hook: Fires when the WP_Customize_Setting::save() method is called.目录锚点:#说明#参数#源码说明(Description)钩子名称的动态部分,$this->id_data...

日期:2020-08-15 15:47:24 浏览:775

customize_value_{$this->id_data[‘base’]}

apply_filters( "customize_value_{$this->id_data[‘base’]}", mixed $default )过滤器::过滤未作为主题模式或选项处理的自定义设置值。Filter Hook: Filter a Customize setting value not handled as a theme_mod or option.目录锚点:#说明#参数#源码说明(Description)钩子名称的动态部分,$this->id_date['base'],指的是设置...

日期:2020-08-15 15:47:24 浏览:866

get_comment_author_url

过滤钩子:过滤评论作者的URL。Filter Hook: Filters the comment author’s URL.目录锚点:#源码源码(Source)更新版本源码位置使用被使用 wp-includes/comment-template.php:32610...

日期:2020-08-10 23:06:14 浏览:903

network_admin_edit_{$_GET[‘action’]}

do_action( "network_admin_edit_{$_GET[‘action’]}" )操作挂钩:启动请求的处理程序操作。Action Hook: Fires the requested handler action.目录锚点:#说明#源码说明(Description)钩子名称的动态部分$u GET['action']引用请求的操作的名称。源码(Source)更新版本源码位置使用被使用3.1.0 wp-admin/network/edit.php:3600...

日期:2020-08-02 09:56:09 浏览:848

network_sites_updated_message_{$_GET[‘updated’]}

apply_filters( "network_sites_updated_message_{$_GET[‘updated’]}", string $msg )筛选器挂钩:在网络管理中筛选特定的非默认站点更新消息。Filter Hook: Filters a specific, non-default site-updated message in the Network admin.目录锚点:#说明#参数#源码说明(Description)钩子名称的动态部分$_GET['updated']引用了非默认的...

日期:2020-08-02 09:56:03 浏览:834

pre_wp_is_site_initialized

过滤器::过滤在访问数据库之前是否初始化站点的检查。Filter Hook: Filters the check for whether a site is initialized before the database is accessed.目录锚点:#源码源码(Source)更新版本源码位置使用被使用 wp-includes/ms-site.php:93910...

日期:2020-07-29 10:15:38 浏览:809

WordPress 的SEO 教学:如何在网站中加入关键字(Meta Keywords)与Meta 描述(Meta Description)?

你想在WordPress 中添加关键字和meta 描述吗?关键字和meta 描述使你能够提高网站的SEO。在本文中,我们将向你展示如何在WordPress 中正确添加关键字和meta 描述。为什么要在WordPress 中添加关键字和Meta 描述?关键字和说明让搜寻引擎更了解您的帖子和页面的内容。关键词是人们寻找您发布的内容时,可能会搜索的重要词语或片语。而Meta Description则是对你的页面和文章的简要描述。如果你想要了解更多关于中继标签的资讯,可以参考Google的说明。Meta 关键字和描...

日期:2020-10-03 21:18:25 浏览:1620

谷歌的SEO是什么

SEO (Search Engine Optimization)中文是搜寻引擎最佳化,意思近于「关键字自然排序」、「网站排名优化」。简言之,SEO是以搜索引擎(如Google、Bing)为曝光媒体的行销手法。例如搜寻「wordpress教学」,会看到本站的「WordPress教学:12个课程…」排行Google第一:关键字:wordpress教学、wordpress课程…若搜寻「网站架设」,则会看到另一个网页排名第1:关键字:网站架设、架站…以上两个网页,每月从搜寻引擎导入自然流量,达2万4千:每月「有机搜...

日期:2020-10-30 17:23:57 浏览:1263