我举一些例子:
>我有一个time zone IDs的下拉列表,当用户选择他的时区我正在更新数据库.在其他应用程序中,我从数据库中提取该值并重新计算用户当前时间和日期.可以选择DB中的数据拼写错误(DB或bug中的硬编码更改).在用户的日期时间的转换方法我正在使用try和catch,有些人告诉我这是错误的!我可以使用for循环来检查数据库中的值,但是每次转换日期时间都会花费更多…
>我必须声明XML文件是否使用此代码格式良好:
protected bool IsValidXML(string xmlFile) { try { XmlDocument doc = new XmlDocument(); doc.LoadXml(xmlFile); } catch(XmlException ex) { ///write to logger return false; } return true; }
我看不到任何其他方法来检查xml文件.
>有时我在我的应用程序中有一部分我正在写一个文件.写入文件可能会导致exeprtion,原因有很多,其他一些进程在写入或其他时使用此文件.所以我通常使用这段代码:
using (StreamWriter w = new StreamWriter(fs)) { try { w.Write("** (Line) " + someValue + " **" + Environment.NewLine); w.Flush(); } catch(IOExeption ex){} finally { w.Close(); } }
总之,我看到了一些使用try和catch以及不使用方法的方法.我看到的文章中的一句话说如果发生异常,你需要知道它.,但是在大多数时候处理泛型应用程序时,我知道会发生异常,但大多数时候我真的不知道它为什么会发生,所以我以前无法捕捉它(就像我写的那些例子),所以何时最好使用try和catch
在ASP.NET中的同一级别,页面有一个Error事件,您可以像这样捕获:
this.Error += new EventHandler(Page_Error); //this = instance of System.Web.UI.Page
事件是否与try catch问题相同?
解决方法
> How to Design Exception Hierarchies by Krzysztof Cwalina
> Vexing exceptions by Eric Lippert
> API Design Myth: Exceptions are for “Exceptional Errors” by Krzysztof Cwalina
关于你的例子:
在案例1中你可能确实想要防守.但是请确保你在那个捕获块中做了一些明智的事情.
案例2看起来很合理,但是您只是将XML文档丢弃.处理它会没有意义吗?
在案例3中,你最后使用try,这绝对不是try catch.在您的具体示例中,您甚至不需要它,因为using statment已经确保文件将被关闭.