寻找有关异常处理的整体方法的提示/写作 [英] Looking for Tips/Writeup on overall approach to Exception Processing

问题描述

Re：寻找关于异常整体方法的提示/写作

处理


大家好 - 我很公平C＃的新手，我想知道如何在我的（合理大小的）C＃Windows

应用程序中最好地实现

（整体）异常处理。我确实在这个

上有一堆随机的问题，如果你能帮助我只有一个或几个，那仍然是

APPRECIATED。以下是我的问题：


1.是否建议将所有主要放入在尝试

块内编码（以及捕获所有异常的catch），以便您的

应用程序永远不会异常终止？


2.当你阅读以下内容时，要意识到我没有明确的

整体方法......以下大部分介绍了一些
在我考虑我的设计时，最初发生在我身上的
问题。

所以这里是：让我们说出我的应用程序的大部分或全部方法

返回一个bool来表示例程是否成功完成

。布尔值等于假值。只有在出现逻辑错误或系统错误的情况下 - 永远不会由于用户输入的某些无效

而从未发生，例如，因为找不到用户文件。以这种方式做这件事是否意味着什么？如果是这样，如果调用程序总是

检查这个false所有被调用方法的值??? （可能是

很多代码！）并且用户看到的错误消息是否总是来自被调用的例程？这是否意味着我会在每个被调用的方法中实现一个

Try块???我非常感谢

任何能帮助我解决所有问题的人......这让我感到... ...


3.有谁知道Web上的任何文档都有一些提示和/或

建议的异常处理的整体方法？


谢谢！


Rex

Re: Looking for Tips/Writeup on overall approach to Exception
Processing

Hi All - I am fairly new to C# and am wondering how to best implement
(overall) Exception Processing within my (reasonably-sized) C# Windows
application. I do have a bunch of somewhat random questions on this
and if you can help me with only one or a few, that would still be
APPRECIATED. Here are my questions:

1. Is it recommended to put all of the "Main" coding within a "try"
block (along with a "catch" that catches all Exceptions) so that your
application will never abnormally terminate?

2. As you read the following, realize that I do NOT have a clear
overall approach for this... So much of the following describes some
questions that have initially occurred to me as I consider my design.
So here goes: Let''s say most or all of my Application''s methods
return a bool to indicate whether the routine successfully completed
or not. The bool will be equal to "false" ONLY if there is a logic
error or system error - never due to some invalid input from the User
and never, for example, because a User file is not found. Does it make
sense to do it this way? And if so, should the calling routine always
check for this "false" value on all called methods??? (which could be
alot of code!) And should the error message that the User sees always
come from the called routine? And does this mean I would implement a
Try block in every called method??? I would very much appreciate
anyone who can help me sort all of this out... which brings me to...

3. Does anyone know of any document on the Web with some tips and/or
suggested overall approaches to Exception Processing?

Thanks!

Rex

推荐答案

2007年6月7日星期四14:43:34 -0700，Rex< Re ******* ***@OneSimpleHabit.com>

写道：

On Thu, 07 Jun 2007 14:43:34 -0700, Rex <Re**********@OneSimpleHabit.com>
wrote:

1.是否建议将所有主要放入在尝试

块内编码（以及捕获所有异常的catch），以便您的

应用程序永远不会异常终止？

1. Is it recommended to put all of the "Main" coding within a "try"
block (along with a "catch" that catches all Exceptions) so that your
application will never abnormally terminate?

我不知道推荐什么。但是我不会打扰，除非我有一些特殊的清理 - 退出前的东西我必须确保发生的事情，或者如果我的应用程序有一些的话，我会b / b
从一个例外中明智地恢复的方式

*而不是*退出。


毕竟，如果你没有特别的清理工作，那你就是'回到

做是抓住异常然后退出，那就是Windows已经为你做了什么
。 :)

I don''t know what''s recommended. But I wouldn''t bother, unless I had some
specific sort of cleanup-before-exit stuff I had to make sure happened, or
if my application had some way to sensibly recover from an exception
*instead* of exiting.

After all, if you have no special cleanup to do, and all you''re going to
do is catch the exception and then exit, then that''s what Windows does for
you already. :)

2.当您阅读以下内容时，请注意我没有明确的

整体方法...所以下面的大部分内容描述了我在考虑我的设计时最初发生的一些问题。

所以这里是：让我们说我的大部分或全部应用程序的方法

返回一个bool来表示例程是否成功完成了

。布尔值等于假值。只有在出现逻辑错误或系统错误的情况下 - 永远不会由于用户输入的某些无效

而从未发生，例如，因为找不到用户文件。以这种方式做这件事是否意味着什么？

2. As you read the following, realize that I do NOT have a clear
overall approach for this... So much of the following describes some
questions that have initially occurred to me as I consider my design.
So here goes: Let''s say most or all of my Application''s methods
return a bool to indicate whether the routine successfully completed
or not. The bool will be equal to "false" ONLY if there is a logic
error or system error - never due to some invalid input from the User
and never, for example, because a User file is not found. Does it make
sense to do it this way?

我不这么认为，不是在.NET中。我仍然有返回boolean

结果的方法，但它们只在被认为是正常情况下才这样做。我不会写一个返回布尔值的方法，但是应该在

理论中永远不会返回false （或true，取决于你如何定义

结果:)）。这对我来说似乎是一种浪费，而且恰好是异常有用的那种情况。


毕竟，如果你的方法返回一个值应始终为true，

但您需要调用者检查返回值，其中的好处是什么？
？调用者应该使用无效的返回值做什么？

将值传播回调用者？难道你不知道

你有什么例外吗？

I don''t think so, not in .NET. I still have methods that return boolean
results, but they do so only in what are considered normal situations. I
would not write a method that returns a boolean, but which should in
theory never return "false" (or "true", depending on how you define the
result :) ). That seems like a waste to me, and is exactly the kind of
situation in which exceptions are useful.

After all, if your method returns a value that should always be "true",
but you require the caller to check the return value, where is the benefit
in that? What is the caller supposed to do with an invalid return value?
Propogate the value back to the caller? Isn''t that what exceptions do for
you already?

如果是这样，调用程序应该总是

检查此false所有被调用方法的值??? （可能是

很多代码！）

And if so, should the calling routine always
check for this "false" value on all called methods??? (which could be
alot of code!)

见上文。 :)

See above. :)

如果用户看到的错误消息总是来自被叫例程？
？

And should the error message that the User sees always
come from the called routine?

例外的另一个好处是它们可以特定于错误的b / b
。有时使用InnerException将

异常包装在另一个异常中是有用的。例如，这将有助于

异常，包括存在一些i / o错误的事实，以及

事实上i / o尝试执行某些更高级别的应用程序操作时发生错误（InnerException将是文件访问类抛出的一个元素，例如FileStream，而

包装异常将被更高级别的应用程序代码抛出

尝试进行某些操作。

Another benefit of exceptions is that they can be specific to what went
wrong. Sometimes it is useful to use the InnerException to wrap an
exception in another exception. This would aid, for example, in having an
exception include both the fact that there was some i/o error, as well as
the fact that the i/o error occurred while trying to perform some
higher-level application operation (the InnerException would be the one
thrown by the file access class, like FileStream for example, while the
wrapping exception would be thrown by the higher-level application code
that was trying to do some operation).

这是否意味着我会在每个被调用的方法中实现一个

Try块???

And does this mean I would implement a
Try block in every called method???

如果你能用

做异常，你应该只实现一个try / catch块。只是为了重新抛出一个例外是没有意义的。

它。在某些情况下，你可能需要做一些清理工作，这将是另外一个理由来捕获异常，但大多数情况下你需要做的任何清理工作都需要做b $ b由使用自动处理用

声明实现IDisposable的对象。

You should only implement a try/catch block if you can do something with
the exception. It is pointless to catch an exception only to just rethrow
it. In some cases, you may need to do some cleanup, which would be
another reason to catch the exception, but most of the time any cleanup
you need to do can be handled automatically by the "using" statement with
objects that implement IDisposable.

我非常感谢

任何可以帮我排序的人所有这一切......带给我的是......


3.有没有人知道网上的任何文件和一些提示和/或$ / b $ b建议了异常处理的整体方法？

I would very much appreciate
anyone who can help me sort all of this out... which brings me to...

3. Does anyone know of any document on the Web with some tips and/or
suggested overall approaches to Exception Processing?

不是副手，没有。但我相信他们在那里。 :)


Pete

Not off-hand, no. But I''m sure they are out there. :)

Pete

6月8日凌晨4:52，Peter Duniho < NpOeStPe ... @nnowslpianmk.com>

写道：

On Jun 8, 4:52 am, "Peter Duniho" <[e-mail]>
wrote:

On Thu，2007年6月7日14:43:34 -0700 ，Rex< RexForum4 ... @ OneSimpleHabit.com>

写道：

On Thu, 07 Jun 2007 14:43:34 -0700, Rex <[e-mail]>
wrote:

1.是否建议将所有的& ;主"在尝试

块内编码（以及捕获所有异常的catch），以便您的

应用程序永远不会异常终止？

1. Is it recommended to put all of the "Main" coding within a "try"
block (along with a "catch" that catches all Exceptions) so that your
application will never abnormally terminate?

我不知道推荐什么。但是我不会打扰，除非我有一些特殊的清理 - 退出前的东西我必须确保发生的事情，或者如果我的应用程序有一些的话，我会b / b
从一个例外中明智地恢复的方式

*而不是*退出。


毕竟，如果你没有特别的清理工作，那你就是'回到

做是抓住异常然后退出，那就是Windows已经为你做了什么
。 :)

I don''t know what''s recommended. But I wouldn''t bother, unless I had some
specific sort of cleanup-before-exit stuff I had to make sure happened, or
if my application had some way to sensibly recover from an exception
*instead* of exiting.

After all, if you have no special cleanup to do, and all you''re going to
do is catch the exception and then exit, then that''s what Windows does for
you already. :)

2.当您阅读以下内容时，请注意我没有明确的

整体方法...所以下面的大部分内容描述了我在考虑我的设计时最初发生的一些问题。

所以这里是：让我们说我的大部分或全部应用程序的方法

返回一个bool来表示例程是否成功完成了

。布尔值等于假值。只有在出现逻辑错误或系统错误的情况下 - 永远不会由于用户输入的某些无效

而从未发生，例如，因为找不到用户文件。以这种方式做这件事是否意味着什么？

2. As you read the following, realize that I do NOT have a clear
overall approach for this... So much of the following describes some
questions that have initially occurred to me as I consider my design.
So here goes: Let''s say most or all of my Application''s methods
return a bool to indicate whether the routine successfully completed
or not. The bool will be equal to "false" ONLY if there is a logic
error or system error - never due to some invalid input from the User
and never, for example, because a User file is not found. Does it make
sense to do it this way?

我不这么认为，不是在.NET中。我仍然有返回boolean

结果的方法，但它们只在被认为是正常情况下才这样做。我不会写一个返回布尔值的方法，但是应该在

理论中永远不会返回false （或true，取决于你如何定义

结果:)）。这对我来说似乎是一种浪费，而且恰好是异常有用的那种情况。


毕竟，如果你的方法返回一个值应始终为true，

但您需要调用者检查返回值，其中的好处是什么？
？调用者应该使用无效的返回值做什么？

将值传播回调用者？难道你不知道

你有什么例外吗？

I don''t think so, not in .NET. I still have methods that return boolean
results, but they do so only in what are considered normal situations. I
would not write a method that returns a boolean, but which should in
theory never return "false" (or "true", depending on how you define the
result :) ). That seems like a waste to me, and is exactly the kind of
situation in which exceptions are useful.

After all, if your method returns a value that should always be "true",
but you require the caller to check the return value, where is the benefit
in that? What is the caller supposed to do with an invalid return value?
Propogate the value back to the caller? Isn''t that what exceptions do for
you already?

如果是这样，调用程序应该总是

检查此false所有被调用方法的值??? （可能是

很多代码！）

And if so, should the calling routine always
check for this "false" value on all called methods??? (which could be
alot of code!)

见上文。 :)

See above. :)

如果用户看到的错误消息总是来自被叫例程？
？

And should the error message that the User sees always
come from the called routine?

例外的另一个好处是它们可以特定于

错误。有时使用InnerException将

异常包装在另一个异常中是有用的。例如，这将有助于

异常，包括存在一些i / o错误的事实，以及

事实上i / o尝试执行某些更高级别的应用程序操作时发生错误（InnerException将是文件访问类抛出的一个元素，例如FileStream，而

包装异常将被更高级别的应用程序代码抛出

尝试进行某些操作。

Another benefit of exceptions is that they can be specific to what went
wrong. Sometimes it is useful to use the InnerException to wrap an
exception in another exception. This would aid, for example, in having an
exception include both the fact that there was some i/o error, as well as
the fact that the i/o error occurred while trying to perform some
higher-level application operation (the InnerException would be the one
thrown by the file access class, like FileStream for example, while the
wrapping exception would be thrown by the higher-level application code
that was trying to do some operation).

这是否意味着我会在每个被调用的方法中实现一个

Try块???

And does this mean I would implement a
Try block in every called method???

如果你能用

做异常，你应该只实现一个try / catch块。只是为了重新抛出一个例外是没有意义的。

它。在某些情况下，你可能需要做一些清理工作，这将是另外一个理由来捕获异常，但大多数情况下你需要做的任何清理工作都需要做b $ b由使用自动处理用

声明实现IDisposable的对象。

You should only implement a try/catch block if you can do something with
the exception. It is pointless to catch an exception only to just rethrow
it. In some cases, you may need to do some cleanup, which would be
another reason to catch the exception, but most of the time any cleanup
you need to do can be handled automatically by the "using" statement with
objects that implement IDisposable.

我非常感谢

任何可以帮我排序的人所有这一切...让我... ...

I would very much appreciate
anyone who can help me sort all of this out... which brings me to...

3.有没有人知道网上的任何文件，并提供一些提示和/或者

建议了异常处理的整体方法？

3. Does anyone know of any document on the Web with some tips and/or
suggested overall approaches to Exception Processing?

不是副手，没有。但我相信他们在那里。 :)


Pete

Not off-hand, no. But I''m sure they are out there. :)

Pete

MSDN的一些最佳实践：
http：//msdn2.microsoft.com/en-us/lib ... ts（VS.71）.aspx


以及一些基本原理： http://msdn2.microsoft.com/en-us/library/

2w8f0bss（VS.71）.aspx


我们再次提供了许多开发人员发布的最佳实践链接：
http://www.codeproject.com/dotnet/ex...tpractices.asp
http://www.c-sharpcorner.com/UploadF...anagement.aspx

Some best practices from MSDN:
http://msdn2.microsoft.com/en-us/lib...ts(VS.71).aspx

And some fundementals:http://msdn2.microsoft.com/en-us/library/
2w8f0bss(VS.71).aspx

Again we have many links for best practices posted by developers:
http://www.codeproject.com/dotnet/ex...tpractices.asp
http://www.c-sharpcorner.com/UploadF...anagement.aspx

嗨Peter和Aneesh，

谢谢你的投入 - 他们都以自己的方式提供帮助！

彼得，几点：1。推广普遍的优势

" try / catch" Main方法中的声明是用户没有得到这个看起来很糟糕的消息，询问用户是否希望向Microsoft发送

错误。它可能是完全相同的消息，但它并不是b $ b看起来一样糟糕。 2.在过去的24小时内，我一直在考虑这个问题，我认为我有一个有趣的解决方案，至少需要尝试一些东西：I
''我将创建一个静态（全局）变量（可能是一个

字符串数组），并将其称为CurrMethodName。然后

在大多数或每个方法的顶部，我要将其值设置为当前方法的

名称。然后我将进行主级别通用

Try / Catch，并显示错误消息和

字符串中的值（用于诊断目的）。如果您或任何人对此有进一步的想法，我是开放的！再次感谢，

Rex

周五，2007年6月8日07:38:09 -0000，Aneesh Pulukkul [MCSD.Net]

< an ****** @ gmail.comwrote：

Hi Peter and Aneesh,
Thank you both your input - they were both helpful in their own way!
Peter, a couple of points: 1. The advantage of putting a universal
"try/catch" statement in the Main method is that the User does not get
the awful-looking message which asks the User if they wish to SEND the
error to Microsoft. It might be the very same message but it doesn''t
look as bad. 2. I''ve been thinking of this issue for the last 24
hours, and I think I have an interesting solution, as least as
something to try: I''m going to create a static (global) variable (a
string array probably) and call it something like CurrMethodName. Then
at the top of most or every method, I''m going to set its value to the
name of the current method. Then I''ll do the Main-level universal
Try/Catch, and display both the error message AND the value in the
string (for diagnostic purposes). If you or anyone has further
thoughts on this, I am open! Thanks again,
Rex
On Fri, 08 Jun 2007 07:38:09 -0000, "Aneesh Pulukkul[MCSD.Net]"
<an******@gmail.comwrote:

> 6月8日凌晨4:52，Peter Duniho < NpOeStPe ... @nnowslpianmk.com>
写道：

>On Jun 8, 4:52 am, "Peter Duniho" <[e-mail]>
wrote:

> 2007年6月7日星期四14:43:34 -0700，Rex < RexForum4 ... @ OneSimpleHabit.com>
写道：

>On Thu, 07 Jun 2007 14:43:34 -0700, Rex <[e-mail]>
wrote:

1.是否建议将所有主要放入在尝试

块内编码（以及捕获所有异常的catch），以便您的

应用程序永远不会异常终止？

1. Is it recommended to put all of the "Main" coding within a "try"
block (along with a "catch" that catches all Exceptions) so that your
application will never abnormally terminate?

我不知道推荐什么。但是我不会打扰，除非我有一些特定类型的清理 - 退出前的东西我必须确保发生，或者
如果我的应用程序有某种方法可以从异常中明智地恢复< * / * *而不是退出。

毕竟，如果你没有特别的清理工作，那么你要做的就是捕获异常，然后退出，那就是Windows已经为你做的事情。 :)

I don''t know what''s recommended. But I wouldn''t bother, unless I had some
specific sort of cleanup-before-exit stuff I had to make sure happened, or
if my application had some way to sensibly recover from an exception
*instead* of exiting.

After all, if you have no special cleanup to do, and all you''re going to
do is catch the exception and then exit, then that''s what Windows does for
you already. :)

2.当您阅读以下内容时，请注意我没有明确的

整体方法...所以下面的大部分内容描述了我在考虑我的设计时最初发生的一些问题。

所以这里是：让我们说我的大部分或全部应用程序的方法

返回一个bool来表示例程是否成功完成了

。布尔值等于假值。只有在出现逻辑错误或系统错误的情况下 - 永远不会由于用户输入的某些无效

而从未发生，例如，因为找不到用户文件。以这种方式做这件事是否意味着什么？

2. As you read the following, realize that I do NOT have a clear
overall approach for this... So much of the following describes some
questions that have initially occurred to me as I consider my design.
So here goes: Let''s say most or all of my Application''s methods
return a bool to indicate whether the routine successfully completed
or not. The bool will be equal to "false" ONLY if there is a logic
error or system error - never due to some invalid input from the User
and never, for example, because a User file is not found. Does it make
sense to do it this way?

我不这么认为，不是在.NET中。我仍然有返回boolean
结果的方法，但它们只在被认为是正常情况下才这样做。我不会写一个返回布尔值的方法，但是
理论中的方法永远不会返回false （或true，取决于您如何定义
结果:)）。这对我来说似乎是一种浪费，而且恰恰是异常有用的那种情况。

毕竟，如果你的方法返回一个值应该始终为true的值。 ，
但你要求来电者检查返回值，其中的好处在哪里？调用者应该使用无效的返回值做什么？
将值传播回调用者？那不是你已经有什么例外吗？

I don''t think so, not in .NET. I still have methods that return boolean
results, but they do so only in what are considered normal situations. I
would not write a method that returns a boolean, but which should in
theory never return "false" (or "true", depending on how you define the
result :) ). That seems like a waste to me, and is exactly the kind of
situation in which exceptions are useful.

After all, if your method returns a value that should always be "true",
but you require the caller to check the return value, where is the benefit
in that? What is the caller supposed to do with an invalid return value?
Propogate the value back to the caller? Isn''t that what exceptions do for
you already?

如果是这样，调用程序应该总是

check对于这个假所有被调用方法的值??? （可能是

很多代码！）

And if so, should the calling routine always
check for this "false" value on all called methods??? (which could be
alot of code!)

见上文。 :)

See above. :)

如果用户看到的错误消息总是来自被叫例程？
？

And should the error message that the User sees always
come from the called routine?

例外的另一个好处是它们可以特定于错误的地方。有时使用InnerException将
异常包装在另一个异常中是有用的。例如，这将有助于有一个例外，包括存在一些i / o错误的事实，以及在尝试执行某些操作时发生i / o错误的事实<更高级别的应用程序操作（InnerException将是文件访问类抛出的一个，例如FileStream，而
包装异常将由更高级别的应用程序代码抛出<那是试图做一些操作。

Another benefit of exceptions is that they can be specific to what went
wrong. Sometimes it is useful to use the InnerException to wrap an
exception in another exception. This would aid, for example, in having an
exception include both the fact that there was some i/o error, as well as
the fact that the i/o error occurred while trying to perform some
higher-level application operation (the InnerException would be the one
thrown by the file access class, like FileStream for example, while the
wrapping exception would be thrown by the higher-level application code
that was trying to do some operation).

这是否意味着我会在每个被调用的方法中实现一个

Try块???

And does this mean I would implement a
Try block in every called method???

如果你可以用异常做什么，你应该只实现一个try / catch块。抓住一个例外只是为了重新抛出它是没有意义的。在某些情况下，您可能需要进行一些清理，这将是捕获异常的另一个原因，但大多数情况下，您需要执行的任何清理都可以通过使用自动处理。 ;用
实现IDisposable的对象的声明。

You should only implement a try/catch block if you can do something with
the exception. It is pointless to catch an exception only to just rethrow
it. In some cases, you may need to do some cleanup, which would be
another reason to catch the exception, but most of the time any cleanup
you need to do can be handled automatically by the "using" statement with
objects that implement IDisposable.

我非常感谢

任何能帮助我解决所有问题的人......带我到...

I would very much appreciate
anyone who can help me sort all of this out... which brings me to...

3.有没有人知道网上的任何文件，并提供一些提示和/或

建议了异常处理的整体方法？

3. Does anyone know of any document on the Web with some tips and/or
suggested overall approaches to Exception Processing?

不是副手，没有。但我相信他们在那里。 :)

Pete

Not off-hand, no. But I''m sure they are out there. :)

Pete

MSDN的一些最佳实践：
http://msdn2.microsoft.com/en-us/lib...ts(VS.71).aspx

以及一些基础知识： http ：//msdn2.microsoft.com/en-us/library/
2w8f0bss（VS.71）.aspx

我们再次提供了许多开发人员发布的最佳实践链接：
http://www.codeproject.com/dotnet/ex ... tpractices.asp
http://www.c-sharpcorner.com/UploadF...anagement.aspx

这篇关于寻找有关异常处理的整体方法的提示/写作的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！