再次异常 [英] Exceptions Again
问题描述
当我的代码检测到
连接断开时（即NetworkStream.Read（）返回0），我应该抛出什么类型的异常？
我应该抛出一个SocketException还是应该创建我自己的类
然后扔掉它 - 这样的情况通常是什么样？
是这样的？
最好的方法是将错误作为参数返回（减少开销）。
如果你必须抛出异常那么你应该继承
ApplicationException。
-
Miha Markic - RightHand .NET咨询&开发
miha at rthand com
www.rthand.com
" C＃Learner" < CS **** @ learner.here>在消息中写道
新闻：例如******************************** @ 4ax.com ...当我的代码检测到
连接断开（即NetworkStream.Read（）返回0）时，我应该抛出什么类型的异常？
我应该抛出一个SocketException还是应该创建自己的类
然后抛出它 - 在这种情况下通常的做法是什么？
" Miha Markic" < miha at rthand com>写道：
嗨Miha，
最好的方法是将错误返回为参数（减少开销）。
如果你必须抛出异常，那么你应该从
ApplicationException继承。
这很有趣 - 在我目前的代码，我已经做了一些事情
这样：该方法返回一个成功值，表明
连接是否丢失（如果丢弃则为false）。我昨晚看了这段代码
，并认为抛出一个异常可能是更多的.NET
做这样的事情的方式，并考虑改变
代码抛出异常。
嗯，我想这是有争议的事情之一...
干杯
Miha Markic写道：
最好的方法是将错误返回为参数（少开销）。
鉴于OP（连接丢失）的问题，我会说开销是无关的。
无关紧要。据推测，错误很少发生。在这样的
场景中，异常方法往往比等效错误更快，因为只要没有异常，try-blocks就会比ifs更快
被抛出。当错误/成功信息必须通过许多调用堆栈级别传播时，尤其如此。
即使连接频繁丢弃，例外的开销也是如此/>
与通过网络进行通信所花费的时间相比通常很小。
因此，我相信使用返回值来表示错误不是很好
的想法在OP的情况下。通常，人们应该避免优化（和b / b
经常混淆）从未被分析过的代码。程序员通常会非常糟糕地猜测会有什么，不会是表现
瓶颈。
如果你必须抛出异常那么你应该从ApplicationException继承
。
这或多或少是微软在MSDN中推荐的。然而，当仔细检查
时，这条规则并没有多大意义。对于
的初学者，即便是微软也不遵循这一指导原则。否则例如
TargetInvocationException将不是ApplicationException的子类
和作为SystemException的子类的所有派生最多的异常类型
将被密封。
此外，还有相当多的框架异常，其中实现你的
自己的ApplicationException派生的对应物只会添加更多的代码
（例如ArgumentException， ArgumentNullException，
ArgumentOutOfRangeException）。每当抛出这样的异常时，整个
过程无论如何都必须被拆除（或至少输入一个故障
模式，技术人员可以诊断问题），为什么是否更好地使用不同的
（ApplicationException派生）异常来表示用户代码中的等效问题？
由此产生的补救措施恰好与b $ b相同，并且最终的原因总是可以通过检查
堆栈跟踪来确定。
仅当框架时还没有提供例外情况，如果您实施自己的
例外情况，可以传达您想要输入的信息。即便如此，最好还是看看框架是否提供了合适的基础类，以便您的用户能够对基础上的
捕获对类似问题作出反应。
问候，
安德烈亚斯
What type of exception should I throw when my code detects that a
connection has dropped (i.e. NetworkStream.Read() returns 0)?
Should I just throw a SocketException or should I create my own class
and throw that instead -- what would be the usual practise in a case
like this?
Hi,
The best way would be to return the error as a parameter (less overhead).
If you have to throw an exception then you should inherit from
ApplicationException.
--
Miha Markic - RightHand .NET consulting & development
miha at rthand com
www.rthand.com
"C# Learner" <cs****@learner.here> wrote in message
news:eg********************************@4ax.com...What type of exception should I throw when my code detects that a
connection has dropped (i.e. NetworkStream.Read() returns 0)?
Should I just throw a SocketException or should I create my own class
and throw that instead -- what would be the usual practise in a case
like this?
"Miha Markic" <miha at rthand com> wrote:
Hi,
Hi Miha,
The best way would be to return the error as a parameter (less overhead).
If you have to throw an exception then you should inherit from
ApplicationException.
This is interesting -- in my current code, I''m already doing something
like this: the method returns a success value indicating if the
connection dropped (false if dropped). I was looking at this code
last night and thought that throwing an exception might be a more .NET
way of doing something like this, and was considering changing the
code to throw an exception instead.
Well, I guess this is one of those debatable things...
Cheers
Miha Markic wrote:Hi,
The best way would be to return the error as a parameter (less
overhead).
Given the problem of the OP (connection dropped) I would say the overhead is
irrelevant. Presumably the error happens very infrequently. In such a
scenario the exception approach tends to be faster than the equivalent error
return-code because try-blocks are faster than ifs as long as no exception
is thrown. This is especially true when the error/success information must
be propagated over many call-stack levels.
Even if connections are dropped frequently, the overhead of exceptions is
typically small compared to the time spent communicating over the network.
Therefore, I believe using return values to signal an error is not a good
idea in OP''s situation. Generally one should refrain from optimizing (and
often also obfuscating) code that has never been profiled. Programmers are
usually very bad at guessing what will and will not be a performance
bottleneck.
If you have to throw an exception then you should inherit
from ApplicationException.
This is more or less what Microsoft recommends in MSDN. However, when
examined closely, this rule does not make a whole lot of sense. For
starters, even Microsoft does not follow this guideline. Otherwise e.g.
TargetInvocationException would not be a subclass of ApplicationException
and all most-derived exception types that are subclasses of SystemException
would be sealed.
Moreover, there are quite a few framework exceptions where implementing your
own ApplicationException-derived counterpart adds nothing but more code
(e.g. ArgumentException, ArgumentNullException,
ArgumentOutOfRangeException). Whenever such an exception is thrown the whole
process must presumably be teared down anyway (or at least enter a fault
mode where a technician can diagnose the problem), so why is it better to
signal an equivalent problem in user-code with a different
(ApplicationException-derived) exception? The resulting remedy is exactly
the same and the ultimate cause can always be determined by examining the
stack-trace.
Only when the framework does not yet offer an exception that could convey
the information you want to put into it should you implement your own
exceptions. Even then it is a good idea to see whether the framework offers
a suitable baseclass so that your users can react to similar problems with a
catch on the base.
Regards,
Andreas
这篇关于再次异常的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
