处理异常与首先防止异常发生 - C#

发布于 2024-07-13 19:47:27 字数 596 浏览 7 评论 0原文

我有一个带有日期时间的 asp:BoundColumn? asp:GridView.data 中的数据(我将其称为 X 列)。 我循环遍历网格中的所有行,并将 .Text 属性转换为 X 列到 DateTime (我需要它进行一些检查并根据需要更改单元格背景颜色)。

我有 2 个选项:

  1. 将转换包装在 try/catch 中...处理 FormatException(以防 X 列渲染时包含一些垃圾)...并且仅使用有效的 DateTime 值。

  2. 检查 X 列以确保它是 之前以正确的格式(如何?) 大小写,并且仅在格式为 好的。

我应该采取哪种方法,为什么?

谢谢。

ps 1 对所有解释投赞成票,TryParse 已接受的答案

编辑2:即使我使用了 TryParse,我也未选中已接受的答案以继续讨论。

我的“好数据”/“坏数据”比率约为 2/1 - 这意味着大量错误的输入

如果没有其他结果,我会在几天内重新接受答案。

I have a asp:BoundColumn with DateTime? data (i'll call it column X) in the asp:GridView. I loop through all the rows in the grid, and cast the .Text property to column X to DateTime (i need this to do some checking and change the cell background color if needed).

I have 2 options:

  1. wrap the cast in try/catch ... handle FormatException (in case column X gets rendered with some junk in it) ... and work only with valid DateTime values.

  2. check the column X to make sure it's
    in the correct format (how?) before
    casing, and only cast if format is
    ok.

Which approach should i take, and why?

Thank you.

p.s. 1 up-vote for all explanations, accepted answer for TryParse

Edit2: even though i used TryParse, I've unchecked the accepted answer to keep the discussion going.

My "good data"/"bad data" ratio is about 2/1 - this means lots of bad input

I'll re-accept the answer in a couple of days, if nothing else comes up.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(7

决绝 2024-07-20 19:47:28

需要注意的一件事是,“TryParse”不一定比在“Parse”周围使用 Try Catch 具有更好的性能。

这取决于你的失败率。 Try-Catch 会对性能产生影响,尽管大部分影响是在失败时产生的。
然而,如果你有 95% 的成功率,甚至更高,并且性能是一个考虑因素,那么你可能需要考虑将你的循环包装在 try-catch 中,这样你只有在出现异常时才会触发“try”语句。失败。

int i = 0;
List<String> prePopulated;
List<DateTime> toPopulate;

while(i < prepopulated.Length)
{
   Try
   {
      while(i < prepopulated.Length)
      {
         List<DateTime>.add(DateTime.Parse(prePopulated[i]));
         i++;
      }
   }
   Catch(Exception ex)
   {
      //log if necessary
      i++;
   }
}

请记住,只有当您的数据基本干净并且性能是关键时,该解决方案才会更好。
否则,越简单的一行“TryParse”越好。

One thing to note is that "TryParse" will not necessarily be better performance than having a Try Catch around your "Parse".

It depends on your failure rate. Try-Catch's have a performance impact, although most of the impact is when you fail.
However, if you have a 95% success rate, or even higher, and performance is a consideration, then you might want to think about wrapping your loop in a try-catch, so that you only hit your "try" statement when there's a failure.

int i = 0;
List<String> prePopulated;
List<DateTime> toPopulate;

while(i < prepopulated.Length)
{
   Try
   {
      while(i < prepopulated.Length)
      {
         List<DateTime>.add(DateTime.Parse(prePopulated[i]));
         i++;
      }
   }
   Catch(Exception ex)
   {
      //log if necessary
      i++;
   }
}

Keep in mind, that solution is only better if your data is primarily clean and performance is key.
Otherwise, the simpler one line "TryParse" is better.

她说她爱他 2024-07-20 19:47:28

我同意 DateTime.TryParse 的观点。 我在一个非常大容量的网站上工作,我们永远不允许捕获 UI 中的异常!这有助于我们防止错误。 我们非常努力地确保我们调用的代码不会抛出异常。

I agree with DateTime.TryParse. I work on a very high volume site and we're not allowed to catch exceptions in the UI, ever!, which helps us to prevent bugs. We try really hard to make sure the code we're calling cannot throw exceptions.

深爱成瘾 2024-07-20 19:47:27

你可以选择第二个选项。 DateTime.TryParse 可以提供帮助。

You could do the 2nd option. DateTime.TryParse can help.

千と千尋 2024-07-20 19:47:27

我认为这在一定程度上取决于您期望其格式错误的频率。 如果很少引发异常,那么将某些内容包装在 try-catch 中实际上根本没有任何影响。 但如果你预计它会被提高很多,那么你也许应该添加一张支票。

I think it depends a bit on how often you expect it to be in the wrong format. Wrapping something in a try-catch doesn't really have any impact at all if the exception is seldom raised. But if you expect it to be raised, a lot, then you should maybe add a check to it.

谁把谁当真 2024-07-20 19:47:27

我会选择第二种选择。 我从不对常规代码使用异常,因为这样我就可以使用 Visual Studio 选项“抛出异常时进入调试器”来运行。

这在识别代码中的实际问题时节省了我很多时间,因为调试器将停在实际问题处而不是其他地方。 如果异常用于无问题的问题,我无法可靠地做到这一点。

I would go for the second option. I never use exceptions for regular code, because then I can run with the visual studio option "break into debugger when exception is thrown".

This saves me a lot of time when identifying real problems in code, because the debugger will stop at the actual problem instead of somewhere else. If exceptions are used for non-problematic issues I cannot do this reliably.

假面具 2024-07-20 19:47:27

异常需要大量资源来引发和捕获。 当有更优雅的选项可用时,您应该避免让它们被抛出。

Exceptions take a lot of resources to raise and catch. You should avoid letting them be thrown when there are more elegant options available.

心碎的声音 2024-07-20 19:47:27

我遵循的规则是:始终尝试手动捕获尽可能多的错误,并将异常作为最后的手段。

异常会对性能产生影响。

A rule I follow: Always try to catch as many errors manually as you can, and use exceptions as a last resort.

Exceptions have an impact on performance.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文