blocks|key|374059|text|我认为这取决于你运行的是哪种应用程序，以及“死亡”的后果是什么。对于许多客户端应用程序来说，死亡是一件可怕的事情。对于服务器，通常不是那么多(并且吞咽和日志是合适的)。没有万能的解决方案。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|374060|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I think it depends on what kind of app you are running and what the consequences of 'dying' are. For many client apps, dying is awesome. For servers, often not so much (and swallow-and-log is appropriate). There's no one-size-fits-all solution.

blocks|key|4438479|text|也称为攻击性编程。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4438480|你应该去看看，"Offensive+Programming:+Crash+Early,+Crash+Often“。|offset|length|4438481|这是一种与Defensive+Programming规范截然不同的思想|4438482|4438483|防御性编程旨在确保一件软件的连续功能，尽管该软件的使用是不可预见的。|blockquote|4438484|4438485|4438486|我个人喜欢“早崩溃，经常崩溃”的哲学。|4438487|我见过太多了：|4438488|try++
{++
++++//+...+Huge+block+of+code+goes+here++
}++
catch(Exception+ex)++
{++
+++//+Do+nothing...++
}++|code-block|syntax|javascript|4438489|这远比撞车更糟糕。如果异常处理得当，那么一点防御性编程就可以了。|4438490|entityMap|0|LINK|mutability|MUTABLE|url|http://blogs.23.nu/c0re/offensive-programming-crash-early-crash-often/|1|http://en.wikipedia.org/wiki/Defensive_programming^0|0|8|1B|0|0|5|L|1|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|18|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|19|8|@]|9|@$D|1A|E|1B|1|1C]]|A|$]]|$1|F|3|G|5|6|7|1D|8|@]|9|@$D|1E|E|1F|1|1G]]|A|$]]|$1|H|3|-4|5|6|7|1H|8|@]|9|@]|A|$]]|$1|I|3|J|5|K|7|1I|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|1J|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|1K|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1L|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1M|8|@]|9|@]|A|$]]|$1|R|3|S|5|T|7|1N|8|@]|9|@]|A|$U|V]]|$1|W|3|X|5|6|7|1O|8|@]|9|@]|A|$]]|$1|Y|3|-4|5|6|7|1P|8|@]|9|@]|A|$]]]|Z|$10|$5|11|12|13|A|$14|15]]|16|$5|11|12|13|A|$14|17]]]]

Also known as Offensive Programming. 

You should check out, "<a href="http://blogs.23.nu/c0re/offensive-programming-crash-early-crash-often/" rel="noreferrer">Offensive Programming: Crash Early, Crash Often</a>".

Which is a very different ideology from the norm of <a href="http://en.wikipedia.org/wiki/Defensive_programming" rel="noreferrer">Defensive Programming</a>:

<blockquote>
 [Defensive Programming] is intended to
 ensure the continuing function of a
 piece of software in spite of
 unforeseeable usage of said software.
</blockquote>

I personally like the "Crash Early, Crash Often" philosophy.

I've seen far too many: 

<pre><code>try 
{ 
 // ... Huge block of code goes here 
} 
catch(Exception ex) 
{ 
 // Do nothing... 
} 
</code></pre>

Which is far worse than crashing hard. If exceptions are handled properly then a little defensive programming is fine.

blocks|key|1054604|text|这完全取决于您如何处理异常。如果您只在发生真正异常的情况时抛出异常(而不是当数据库查询没有返回任何结果或格式错误时)，那么您真的不需要捕获异常。因为您的程序不应该能够恢复，所以您可以恢复的任何东西都不是异常，而是一个错误。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1054605|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

That all depends on how you treat exceptions. If you only throw exceptions when something truly exceptional has happened (and not when a database query return no results, or is ill-formed) then you really shouldn't need to ever catch exceptions. Because your program shouldn't be able to recover, anything you can recover from is not an exception, but an error.

blocks|key|1050012|text|Karl+Seguin对异常处理的描述如下：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1050013|1050014|仅处理您可以对|ordered-list-item|1050015|执行某些操作的异常您无法对|1050016|的绝大多数异常执行任何操作|1050017|很好地介绍了这个主题。|1050018|entityMap|0|LINK|mutability|MUTABLE|url|http://codebetter.com/blogs/karlseguin/archive/2008/05/29/foundations-of-programming-pt-8-back-to-basics-exceptions.aspx^0|0|B|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@$A|W|B|X|1|Y]]|C|$]]|$1|D|3|-4|5|6|7|Z|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|10|8|@]|9|@]|C|$]]|$1|H|3|I|5|G|7|11|8|@]|9|@]|C|$]]|$1|J|3|K|5|6|7|12|8|@]|9|@]|C|$]]|$1|L|3|M|5|6|7|13|8|@]|9|@]|C|$]]|$1|N|3|-4|5|6|7|14|8|@]|9|@]|C|$]]]|O|$P|$5|Q|R|S|C|$T|U]]]]

<a href="http://codebetter.com/blogs/karlseguin/archive/2008/05/29/foundations-of-programming-pt-8-back-to-basics-exceptions.aspx" rel="noreferrer">Karl Seguin</a> says the following about exception handling:

<ol>
<li>Only handle exceptions that you can actually do something about</li>
<li>You can't do anything about the vast majority of exceptions</li>
</ol>

Good intro to the subject.

blocks|key|4438252|text|这是典型的微软风格。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4438253|MS希望您向WER抛出所有未处理的异常。(Windows错误报告，这是当应用程序崩溃时将错误发送给microsoft的对话框)|4438254|这样，您就可以获得使用指标，并可以专注于导致客户痛苦的关键未处理异常。我相信这个想法是它迫使你去思考异常来自哪里。|4438255|但我完全同意你的观点。即使你在之后重新抛出，你也总是会在根上捕获一个未处理的，记录所发生的事情。唯一的问题是，如果你未经处理的ex是内存不足，在这种情况下，你对日志的调用可能会失败，因为JIT不能再分配更多的内存，等等。我认为C%2B%2B程序通过获取大量内存，在一个未处理的异常上释放它，然后运行一个非常紧凑的日志例程来尝试，然后优雅地失败。|4438256|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

This is very microsoft.

MS want you to throw all unhandled exceptions to WER. (Windows error reporting, its the dialog you get to send your error to microsoft when an app crashes)

That way you get usage metrics and can focus on the key unhandled exceptions which are causing customers grief. I believe the idea is it forces you to think about where the exceptions will come from.

But I wholeheartedly agree with you. Even if you rethrow after, you would always catch an unhandled at the root, log what happened. The only problem with this is if your unhandled ex is an out of memory in which case your call to log could fail as the JIT can't allocate any more memory etc. I think C++ programs deal with this by taking a bubble of memory, releasing it on an unhandled exception and then running a very tight log routine to try and fail gracefully.

blocks|key|3591650|text|我不熟悉Richter的材料，但我认为其中的哲学/理由是，在绝大多数情况下，程序真的无法从未处理和意外的异常中恢复。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3591651|然而，让程序死在用户面前并不是一个很好的主意--它会给人留下一个非常糟糕的印象。我更喜欢将未处理的异常记录到数据库中，通知开发人员，并跟踪它们以确保它们得到修复。|3591652|再说一次，我销售的产品正是为了这个目的，所以我在这个领域有点偏见！|3591653|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

I am not familiar with Richter's material, but I think the philosophy/justification is that in the vast majority of cases there is really nothing that the program can do to recover from an unhandled and unexpected exception.

Letting the program die in front of a user, however, is not a very good idea - it leaves a very bad impression. I prefer to log unhandled exceptions to a database, notify the developers, and track them to make sure that they get fixed.

Then again, I sell a product for exactly that purpose, so I am a bit biased in this area!

blocks|key|1054729|text|如果你不能很好地处理这个问题--如果它只是以某种形式拒绝错误的输入(这包括你试图从磁盘或web读取的东西)，你可能不能--那么你应该死。除非你100%25确定你可以安全地继续，否则不要。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1054730|然而，我不会简单地让一个异常过去。捕捉它并收集尽可能多的信息。如果您的程序操作了某种类型的文档，请将其保存为新名称--它可能已损坏，您不希望覆盖原始文档。|1054731|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

If you can't handle the problem adequately--and if it's anything other than rejecting bad input in some form (this includes something you tried to read from the disk or web) you probably can't--then you should die. Unless you're 100% certain you can continue safely, don't.

However, I wouldn't simply let an exception go. Catch it and gather as much information as you can. If your program manipulates a document of some kind save it UNDER A NEW NAME--it might be corrupt, you don't want to overwrite the original.

blocks|key|4438712|text|没有什么比堆栈跟踪更快地摧毁用户信心了。至少，捕获异常并记录尽可能多的信息。然后，向用户提供一条友好的消息和说明，说明如何解决问题或向支持部门报告问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4438713|这里有关于继续处于不确定状态的担忧。如果这是一个web应用程序，那么这不是问题，除非您过度依赖会话和应用程序状态。如果这是一个windows应用程序，那么可以随时退出(在给用户一个保存的机会之后)。|4438714|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Nothing destroys user confidence faster than a stack trace. At a minimum, catch the exception and log as much information as you can. Then provide the user with a friendly message and instructions as to what to do to either work around the issue or report the problem to support.

There is concern here as to continuing in an indeterminate state. If this is a web app, then this is not a problem unless you are overly dependent on session and app state. If this is a windows app, then feel free to exit (after giving the user a chance to save).

blocks|key|374646|text|由于您不知道Exception的每个子类是什么，所以您根本不知道捕获它们是可以的。因此，您应该关注自己的事情:捕获您知道并关心的异常，这些异常主要是您为自己的程序显式创建的异常，或者是为您正在使用的库调用中的错误而创建的异常。特别是，捕获异常类只是懒惰的、糟糕的编程-本质上，您是在说“我不在乎问题是什么，也不要告诉我；只要这样做就行了。”看看java程序是如何处理异常的，因为那里的异常处理实践通常都很好。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|374647|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Since you don't know what every subclass of Exception IS, you simply CANNOT know it's OK to catch them. Therefore, you should mind your own business: catch exceptions you know and care about, which will mainly be the ones you've explicitly created for your own program, or the ones created for errors from the library calls you're using. In particular, catching the Exception class is just lazy, bad programming --- essentially, you're saying "I don't care what the problem is, and don't tell me; just do this." Take a look at how java programs handle exceptions, as the exception handling practices there are usually pretty good.

blocks|key|1049770|text|您的客户期望什么？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1049771|这一切都回到了这一点上。如果客户可以处理程序的死亡，他们可以重新启动它，那就这样吧。|1049772|有时，更好的做法是让一个进程死亡，然后创建另一个进程来处理请求。|1049773|有时，尝试解决问题会更好。|1049774|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

What does your customer expects?

It all comes back to that. If the customer can handle the program dying and they can restart it, so be it.

Sometimes, it is better to let a process die and create another to handle requests.

Sometimes, it is better to attempt to resolve the problem.

blocks|key|374317|text|我说你应该总是有一个根异常捕获器...特别是如果您可以在异常中拟合某种信息，说明哪里出了问题，代码或其他东西，并将其打印出来给用户。然后，用户可以随时询问您(或支持人员等)哪里出了问题，并提供一些信息。而不是“它因保护故障而崩溃”|type|unstyled|depth|inlineStyleRanges|entityRanges|data|374318|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I say you should always have a root exception catcher... Especially if you can fit some kind of information in the exception saying what went wrong, a code or something and print it out to the user. Then, the user can always ask you(or support or whatever) what went wrong and provide some info.. rather than "it crashed with a protection fault"

blocks|key|3591973|text|根本不处理任何异常有一个好处。如果有问题，你宁愿有一个崩溃和用户抱怨，而不是让程序继续在一个不确定的状态。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3591974|例如，如果您正在编写一个实时交易系统，并且出现意外错误，那么您最好让它崩溃。否则，您的程序可能会继续运行并进行愚蠢的交易。用户会马上抱怨“见鬼？”，但至少你不会损失数百万美元。|3591975|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

There's one advantage of not handling any exceptions at all. If there's a problem, you'd rather have a crash and the user complain, instead of having the program continue in an indeterminate state.

For example, if you're writing a real time trading system, and there's an unexpected error, you're better off letting it crash. Otherwise, your program might keep going and make stupid trades. The users will complain right away "WTF?", but at least you don't lose millions of dollars.

blocks|key|4438773|text|这里已经有了很棒的答案，特别是Simucal。我只想补充一点：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4438774|攻击性编程对于调试来说是极好的。根据我的经验，“过早失败，经常失败”可以被看作是在你的代码中设置bug陷阱。当出现问题时--无论是内存泄漏、内存践踏、意外的NULL等等--如果程序立即失败(带有相关的调试数据，如callstack)，通常更容易看到问题。|4438775|防御性编程非常适合于生产环境。一旦您的应用程序发布了，您可能不希望您的最终用户看到一个漂亮的小对话框，上面写着"unhandled+exception+at+foo()“。如果你的应用程序处于测试版，并且你还在收集调试信息，这可能会很好，但如果你正在发布一个稳定的应用程序，你可能只想在某些东西确实失败的罕见情况下，不想用神秘的输出来打扰用户。|4438776|有时你可以两全其美。我经常按照下面的代码编写C代码：|4438777|void+foo(char*+data)+{
++++ASSERT(data);
++++if+(!data)+{+return;+}
++++//+...+work+with+data
}|code-block|syntax|javascript|4438778|如果此代码是在测试环境中编译的，则assert语句会捕获错误条件。如果它是在生产环境中编译的，则断言将被预处理器删除，foo()将静默失败。|4438779|异常比断言更具表现力和灵活性，并且有多种方法来管理它们，以便应用程序在测试环境中早期失败，并在生产环境中记录错误时继续运行。根据项目类型的不同，这种设计可能对您有意义。|4438780|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|U|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|V|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|W|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|X|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|Y|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

Awesome answers here already, especially by Simucal. I just want to add a point:

Offensive programming is excellent for debugging. In my experience, "fail early, fail often" can be thought of as like setting traps for bugs in your code. When something goes awry--whether it's a memory leak, memory stomp, unexpected NULL, etc.--it's generally much easier to see the problem if the program fails immediately (with associated debugging data such as a callstack).

Defensive programming is excellent for production environments. Once your application has shipped, you may not want your end-users to ever see a nice little dialog saying "unhandled exception at foo()." That might be great if your app is in beta and you're still gathering debug info, but if you're shipping a stable app you might simply want to not bother the user with cryptic output in the rare case that something does fail.

Sometimes you can have it both ways. I've often wrote C code along the following lines:

<pre><code>void foo(char* data) {
 ASSERT(data);
 if (!data) { return; }
 // ... work with data
}
</code></pre>

If this code is compiled in a test environment, the assert statement traps the error condition. If it is compiled in a production environment, the assert is removed by the pre-processor and foo() fails silently.

Exceptions are more expressive and flexible than asserts, and there are various ways to manage them such that an app fails early in a test environment and chugs along while logging errors in a production environment. Depending on the type of project, this sort of design may make sense for you.

blocks|key|3591886|text|使用try+catch的问题是，你经常会“处理”一些你不知道如何恢复的事情。用户得到了一种错误的印象，认为事情进展顺利，但在内部，你会转向瑞士奶酪，并最终以非常奇怪的方式崩溃。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3591887|另一方面，当用户没有办法向您报告异常时，向他们抛出异常并不是那么有帮助|3591888|3591889|当您向|unordered-list-item|3591890|注册时，新的windows服务提供了该功能。安装drwatson还可以捕获数据(转储文件)，以便用户手动发送给您。|3591891|3591892|如果你提供了一个服务库，并且它正在运行，如果你的服务扰乱了整个服务器，扰乱了内存或设置等等，那么当异常被引发时，服务器可能真的需要关闭。|3591893|根据合同，API将倾向于提供一种方式来说“我可以这样做吗”，然后提供一种“这样做”的方式，并且许多API，如MS文件打开，将允许您在引发异常和返回错误代码之间进行切换。|3591894|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|S|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|T|8|@]|9|@]|A|$]]|$1|H|3|I|5|G|7|U|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|V|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|W|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|X|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|P|$]]

The problem with having try catch around everything is that you often end up 'handling' things that you don't know how to recover from. The user gets a false impression that things are going fine, but internally you turn to swiss cheese and eventually break in really strange ways.

On the other hand, throwing the exception up to the user isn't all that helpful when they don't have some way of reporting it too you 

<ul>
<li>the new windows services provide that feature when you register with MS.</li>
<li>installing drwatson can also capture the data (dump files) for your users to send to you manually.</li>
</ul>

If your providing a service library and it's run in process, if your service messes with the overall server messing up memory or settings and such, then perhaps the server will realy need to shut down when the exception is raised.

By contract APIs will tend to provide a way to say 'can I do this' and then a way to 'do it', and many APIs like the MS file open will allow you to change between raising an exception and returning an error code.

blocks|key|374457|text|您可以随时设置自定义错误处理程序，并忽略捕获您不准备处理的异常。如果满足正确的条件，试图从未知中恢复也可能产生负面后果。但话又说回来，这确实取决于异常是什么以及您如何处理它们。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|374458|另一方面，我认为人们会被“例外就是邪恶”的心态压倒。它们是一种工具，如果使用得当，会有惊人的好处。但是，许多人通过使用catch(异常)包装root来滥用它们。|374459|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

You can always setup a custom error handler and ignore catching exceptions that you aren't prepared to handle. Trying to recover from unknowns may have negative consequences too if the right conditions are met. But then again, that really does depend on what the exception is and how you're handling them.

On the other hand - I think people get to overwhelmed with the whole "exceptions are evil" mentality. They are a tool, and if used appropriately, can have astonishing perks. However, many people misuse them by wrapping root with catch(Exception)..

Recently I attended Jeffrey Richter's training courses about .NET. He mentions one strategy of coding "Dying is awesome". That is, don't write "catch (Exception ex)" even at the root of program or event loop. If some exception thrown that is not handled, just let the process die. 

I'm not sure this is right. Personally, I prefer to have a "<code>try {...} catch(Exception ex) {log and try to recover}</code>" to wrap at the top level of execution. Actually, ASP.NET doesn't die if any exception is throw from asXx. If it does die for exception, then one silver-bullet request can silence the whole service.

What do you think?

Is "Dying is Awesome" preferred?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

最近，我参加了Jeffrey Richter关于.NET的培训课程，他提到了一种“死亡很棒”的编码策略。也就是说，即使在程序或事件循环的根部，也不要写"catch (Exception )“。如果抛出了一些未处理的异常，就让进程终止。我不确定这样做对不对。就我个人而言，我更喜欢在执行的顶层使用"try {...} catch(Exception ex) {log and try to recove

问“死亡是可怕的”是首选吗？
EN

回答 15

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问“死亡是可怕的”是首选吗？EN

回答 15

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问“死亡是可怕的”是首选吗？
EN