blocks|key|3332187|text|我会亲自用另一个try\catch语句包装写入事件日志的调用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3332188|但是，这最终取决于您的规范是什么。如果将失败写入事件日志对系统来说很重要，那么您应该允许抛出它。但是，根据您的示例，我怀疑这是您想要做的事情。|3332189|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|$]]

I would personally wrap the call to write to event log with another try\catch statement.

However, ultimately it depends on what your specification is. If it is critical to the system that the failure is written to the event log then you should allow it to be thrown. However, based on your example, I doubt this is what you want to do.

blocks|key|1225472|text|您可以简单地在错误日志记录方法中捕获错误。然而，我个人不会这么做，因为错误日志记录是你的应用程序根本无法工作的标志。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1225473|private+void+SendMail()
{
++++try
++++{
++++++++//i+try+to+send+a+mail+and+it+throws+an+exception
++++}
++++catch(Exception+ex)
++++{
++++++++WriteToLog();
++++}
}

private+void+WriteToLog()
{
++++try
++++{
++++++++//+Write+to+the+Log
++++}
++++catch(Exception+ex)
++++{
++++++++//+Error+Will+Robinson
++++++++//+You+should+probably+make+this+error+catching+specialized+instead+of+pokeman+error+handling
++++}
}|code-block|syntax|javascript|1225474|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

You can simply catch errors in the error logging method. However I wouldn't personally do that, as broken error logging is a sign your application can't function at all.

<pre><code>private void SendMail()
{
 try
 {
 //i try to send a mail and it throws an exception
 }
 catch(Exception ex)
 {
 WriteToLog();
 }
}

private void WriteToLog()
{
 try
 {
 // Write to the Log
 }
 catch(Exception ex)
 {
 // Error Will Robinson
 // You should probably make this error catching specialized instead of pokeman error handling
 }
}
</code></pre>

blocks|key|1228244|text|只有在try-catch块中才能捕获每个异常。您可以嵌套try-catch，但通常不是一个好主意。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1228245|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|$]]

Each exception is caught only when inside a try-catch block. You could nest try-catch but is generally not a good idea.

blocks|key|3332213|text|您也可以在catch块中添加一个try-catch块。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3332214|entityMap^0|5|5|G|9|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|M|8|@]|D|@]|E|$]]]|G|$]]

You could add a <code>try-catch</code> block in your <code>catch</code> block as well.

blocks|key|3332313|text|考虑写入文件时的异常类型(权限、磁盘空间...)我建议你不要在这里处理。如果第一次失败，您很有可能无法写入事件日志，也无法写入事件日志……|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3332314|让它冒泡起来，并由上层的try/catch处理。|3332315|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|$]]

Considering the kind of exceptions when writing to a file (rights, disk space...) I would advice not to handle it in here. If it fails the first time, there's good chance you won't be able to write to the event log that it's not possible to write in the event log...

Let it bubble up and be handled by an upper level try/catch.

blocks|key|1228307|text|克里斯·S有最好的答案。在catch块中放置try-catch块通常不是一个好主意。在你的情况下，它只会使你的代码变得复杂。如果您检查是否在此处成功写入日志文件，则必须在您尝试写入日志文件的每个位置执行此操作。当涉及到通知/处理这些模块中的错误条件时，您可以轻松地避免这种不必要的代码重复，方法是将所有单独的模块包含在内。当发送邮件失败时，您可以在catch块中执行适当的操作来处理这种异常情况，例如：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1228308|1228309|处理邮件对象的内容|ordered-list-item|1228310|确保您的套接字已关闭|1228311|在日志文件中写入一个条目以记录错误|1228312|1228313|在catch块中，只需调用您为将日志条目写入日志文件而定义的任何API，就可以忽略其余的内容。在您的日志API中，您应该处理任何与日志相关的异常情况(磁盘已满、没有写入文件的权限、找不到文件等)。您的邮件模块不需要知道日志记录是否成功，应该将该责任委托给日志记录模块。|1228314|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|P|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|Q|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|R|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|S|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|T|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|U|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|N|$]]

Chris S. has the best answer. Placing a try-catch block inside a catch block is very rarely a good idea. and in your case it will just convolute your code. If you check to see if you were successful in writing to your log file here, you will have to do it in every place where you try to write into your log file. You can easily avoid this unnecessary code duplication by having all your individual modules be self contained when it comes to notifying/handling of error conditions within these modules. When sending your mail fails you perform the proper actions inside your catch block to handle this exceptional condition like:

<ol>
<li>disposing of the contents of your mail object</li>
<li>making sure your socket is closed</li>
<li>writing an entry into your log file to note the error</li>
</ol>

Inside your catch block just call whatever API you have defined to writing a log entry into your logfile and forget about about the rest. Inside your logging API is where you should handle any logging related exceptional cases (the disk is full, no permission to write to file, file not found, etc...). Your mailing module does not need to know if the logging was successful or not, that responsibility should be delegated to the logging module.

blocks|key|480223|text|我个人使用一个简单的扩展方法来处理这种情况。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|480224|public+static+class+MyExtentions
{
++++public+static+void+LogToErrorFile(this+Exception+exception)
++++{
++++++++try
++++++++{
++++++++++++System.IO.File.AppendAllText(System.IO.Path.Combine(Application.StartupPath,+"error_log.txt"),
++++++++++++++++String.Format("{0}\tProgram+Error:+{1}\n",+DateTime.Now,+exception.ToString()));
++++++++}
++++++++catch+
++++++++{+
++++++++++++//+Handle+however+you+wish
++++++++}
++++}
}|code-block|syntax|javascript|480225|用法很简单：|480226|try
{
+++...
}
catch(Exception+ex)
{
+++ex.LogToErrorFile();
}|480227|然后，您可以随心所欲地在扩展方法中处理捕获的异常，或者干脆不捕获它，让它冒泡到顶部。我发现这种设计是一种在整个应用程序中处理异常的简单、可重复的方法。|480228|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Q|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|S|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

I personally handle this situation using a simple extension method.

<pre><code>public static class MyExtentions
{
 public static void LogToErrorFile(this Exception exception)
 {
 try
 {
 System.IO.File.AppendAllText(System.IO.Path.Combine(Application.StartupPath, "error_log.txt"),
 String.Format("{0}\tProgram Error: {1}\n", DateTime.Now, exception.ToString()));
 }
 catch 
 { 
 // Handle however you wish
 }
 }
}
</code></pre>

The usage is simple:

<pre><code>try
{
 ...
}
catch(Exception ex)
{
 ex.LogToErrorFile();
}
</code></pre>

You can then handle the caught exception inside the extension method however you want, or simply don't catch it and let it bubble up to the top. I've found this design to be a simple, reproducible way to handle exceptions throughout the application.

blocks|key|3332586|text|首先，我要说的是，不要在块中捕获“|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3332587|”。相反，对于邮件，检查所有的有效性，然后捕获特定的异常(SmtpException，)，您可以对其做些什么(并用友好的消息通知用户)。从你的代码中抛出异常并通知UI是个不错的主意。如果您的方法接受具有特定规范的输入，而如果它们不满足，那么您的方法应该/可以抛出错误并通知用户。|unordered-list-item|3332588|对于无法控制的异常，请使用全局处理异常，如web的Application_Error。Getting+Better+Information+on+Unhandled+Exceptions+Peter+Bromberg更好地解释了这一点。|offset|length|3332589|还对你正在访问的任何特权资源，如事件日志，确保你的程序集有权访问它。web+Exception+logging|3332590|One的有用链接|3332591|+Build+a+Really+Useful+ASP.NET+Exception+Engine+By+Peter+A.+Bromberg和Documenting+Exceptional+Developers+By+Peter+A.+Bromberg查看Health+monitoring+web应用程序的更多内容，如果您的应用程序出错/抛出无法处理(根本)的错误，最好让它优雅地关闭并不继续。在不稳定状态下应用程序不是一个好主意。|3332592|3332593|entityMap|0|LINK|mutability|MUTABLE|url|http://www.eggheadcafe.com/articles/20051205.asp|1|https://stackoverflow.com/questions/1129915/asp-net-exception-handling-logging|2|http://www.eggheadcafe.com/articles/20030816.asp|3|http://www.eggheadcafe.com/articles/20030127.asp|4|http://www.developerfusion.com/code/5543/health-monitoring-in-aspnet-2/^0|0|0|17|1T|0|0|12|H|1|0|0|1|1V|2|1X|1J|3|3I|H|4|0|0^^$0|@$1|2|3|4|5|6|7|15|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|16|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|17|8|@]|9|@$G|18|H|19|1|1A]]|A|$]]|$1|I|3|J|5|D|7|1B|8|@]|9|@$G|1C|H|1D|1|1E]]|A|$]]|$1|K|3|L|5|D|7|1F|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|1G|8|@]|9|@$G|1H|H|1I|1|1J]|$G|1K|H|1L|1|1M]|$G|1N|H|1O|1|1P]]|A|$]]|$1|O|3|-4|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|1R|8|@]|9|@]|A|$]]]|Q|$R|$5|S|T|U|A|$V|W]]|X|$5|S|T|U|A|$V|Y]]|Z|$5|S|T|U|A|$V|10]]|11|$5|S|T|U|A|$V|12]]|13|$5|S|T|U|A|$V|14]]]]

<ul>
<li>Firstly I would say don't catch "Exception" in catch block. You could instead, for mailing, check for all validity and then catch specific exception(SmtpException, ) that you can do something about(and informing user with a friendly message). Throwing exception from your code and informing the UI about is not a bad idea. If your methods accepts inputs with certain specification and if they are not met, your method should/can throw error and inform user about it. </li>
<li>For exceptions that have no control over, use global handling exception, like Application_Error for web. 
<a href="http://www.eggheadcafe.com/articles/20051205.asp" rel="nofollow noreferrer">Getting Better Information on Unhandled Exceptions Peter Bromberg</a> explains this better.</li>
<li>Also for any privildged resource you are accessing, like eventlogs, make sure you assembly has access to it. </li>
<li>Useful links <a href="http://www.eggheadcafe.com/articles/20030816.asp" rel="nofollow noreferrer">Build a Really Useful ASP.NET Exception Engine By Peter A. Bromberg</a>
and 
<a href="http://www.eggheadcafe.com/articles/20030127.asp" rel="nofollow noreferrer">Documenting Exceptional Developers By Peter A. Bromberg</a>
For web application look into 
<a href="http://www.developerfusion.com/code/5543/health-monitoring-in-aspnet-2/" rel="nofollow noreferrer">Health monitoring</a>
<a href="https://stackoverflow.com/questions/1129915/asp-net-exception-handling-logging">Exception logging</a></li>
<li>One more thing, if your application goes wrong/ throws error that can't handle( at all) its better to let it go down gracefully and not continue. Application in unstable state is not good idea. </li>
</ul>

i know this could be a little weird but a doubt is a doubt afterall...
what would happen in the following situation...

<pre><code>private void SendMail()
{
 try
 {
 //i try to send a mail and it throws an exception
 }
 catch(Exception ex)
 {
 //so i will handle that exception over here
 //and since an exception occurred while sending a mail
 //i will log an event with the eventlog

 //All i want to know is what if an exception occurs here
 //while writing the error log, how should i handle it??
 }
}
</code></pre>

Thank you.

Exception handling within an Exception in C#

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

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

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

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

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

我知道这可能有点奇怪，但怀疑终究是怀疑……在以下情况下会发生什么.private void SendMail(){    try    {        //i try to send a mail and it throws an exception    }    catch(Exception ex)    {        //so i will handle that exception

问C#中异常中的异常处理
EN

回答 8

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问C#中异常中的异常处理EN

回答 8

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问C#中异常中的异常处理
EN