例外与退货代码 [英] Exception vs Return Code

问题描述

亲爱的，


这更像是理论或概念上的问题：

哪个更好，使用异常或返回代码

a .NET组件？


我创建了一个COM对象（使用VB6），它使用返回

代码（不生成错误/异常）因此它与其他编程语言更兼容。


现在我们将COM对象迁移到.NET组件中

但是想知道我是否应该改变我的代码工作

而不是例外？使用

例外有多受欢迎？是否支持所有支持.NET的

编程语言？


谢谢，

Adi

解决方案

例外是可行的方法。是的，所有.NET

语言都支持它们，因为所有语言都支持相同的类库，而

异常类就在那里。


您也可以创建自己的自定义异常，然后给他们自己的描述（消息）以及来源。


通过使用例外，您可以使用结构化异常

处理（尝试... Catch ...最后），这是首选方式。

" ad *@message4u.com" <一个******* @ discussions.microsoft.com>在消息中写道

news：01 **************************** @ phx.gbl ... < blockquote class =post_quotes>亲爱的，

这更像是一个理论或概念问题：
哪个更好，使用异常或返回代码来构建.NET组件？

我创建了一个COM对象（使用VB6），它使用返回代码（不生成错误/异常），因此它与其他编程语言更加兼容。 br />
现在我们正在将COM对象迁移到.NET组件中，但是想知道我是否应该将代码改为工作
而不是异常？
异常的使用有多受欢迎？是否支持所有支持.NET的编程语言？

谢谢，
Adi

嗨斯科特，


谢谢你的回答。我猜下一个问题

将是：为什么例外情况比结果更优惠

代码？它背后有任何技术原因吗？或者它只是新的或时髦的东西。


到目前为止我发现的是大多数非微软语言

可能与异常处理不兼容。我想

使用返回错误代码是旧时尚，但似乎

被广泛接受并且更容易理解（或者可能是

习惯了。）


我必须证明用异常类替换

返回代码所需的时间。所以，一个好的

技术/商业认知将会非常感激。


问候，

Adi

-----原始消息-----
例外是要走的路。是的，它们在所有.NET语言中都支持
，因为所有语言都支持相同的
类库，并且有异常类。

您可以创建自己的自定义异常以及
然后给他们自己的描述（消息）以及来源。

通过使用异常，您可以使用
结构化异常处理（Try ... Catch。 ..最后），这是首选的
方式。

" ad * @ message4u.com" <一个******* @ discussions.microsoft.com>在消息中写道

news：02 **************************** @ phx.gbl ... < blockquote class =post_quotes>嗨斯科特，

谢谢你的回答。我想下一个问题将是：为什么例外情况比结果代码更受欢迎？它背后有任何技术原因吗？或者它只是一些新的或时髦的东西。


不是什么新东西，只是VB的新手。 Java，JavaScript，C& C ++已经使用了

结构化异常处理一段时间了。


结构化异常处理的概念比尴尬的VBOn Error GoTo更加结构化。或On Error Resume Next方式。


它看起来像这样....


尝试

''可能失败的代码去这里

捕获n作为ExceptionType

''当上面提到的ExceptionType被引发时应该运行的代码

''你给的名字例外，n在这种情况下用于

代表异常，因此可以使用标准异常属性来询问

''，例如b $ b。消息" （比如旧的VB描述）和Source（

表示哪个程序集抛出异常

Catch n1 as OtherExceptionType

''同上以上

捕获n99作为例外

''请注意，您测试的最后一个Catch应仅测试一个简单的

例外 ;而不是

''任何特定类型的例外

''这可以作为全部捕获，用于任何您没有具体的例外情况

测试

最后

''此部分不是必需的，但此处的任何代码

''将运行是否有一个例外与否

结束尝试


你可以看到使用这个过程中有更多的结构

方法，因为许多其他语言已经采用这种方式，它是一种一致的错误处理方法。


如果你只是通过代码返回错误，你不会根据定义，这种方法不能使用

结构化异常处理处理

异常类型不是错误代码。

到目前为止我发现的是大多数非Microsoft语言
可能与异常处理不兼容。我想
使用返回错误代码是旧时尚，但它似乎被广泛接受并且更容易理解（或者可能已经习惯了）。


不对，请参阅我的第一行评论。

我必须证明用异常类替换
返回代码所需的时间。因此，将非常感谢良好的技术/业务感知。


比其他语言更多（Java，JavaScript，C，C ++，C＃和

更多）

更强大的时候使用OO语言工作（例外是类和

因此创建自定义异常就像创建一个继承自基本异常类的新类

一样简单。）


希望这会有所帮助！


-Scott

问候，
Adi

-----原始消息-----
例外是要走的路。是的，所有.NET

语言都支持

，因为所有语言都支持相同的

类库和

异常类就在那里。

您也可以创建自己的自定义异常并

然后给它们

自己的描述（消息）以及源。

通过使用异常，您可以使用

结构化异常

处理（尝试... Catch ...最后），这是首选的

方式。

Dear all,

This is more like a theoretical or conceptual question:
which is better, using exception or return code for
a .NET component?

I had created a COM object (using VB6), which uses return
code (not generating error/exception) so it is more
compatible with other programming language.

Now we are migrating the COM object into .NET component
but wondering whether I should change my code to work
with exception instead? How popular is the use of
exception? Is it supported by all .NET-enabled
programming language?

Thanks,
Adi

解决方案

Exceptions are the way to go. Yes, they are supported across all the .NET
languages because all the languages support the same class libraries and the
Exception class is in there.

You can create your own custom exceptions as well and then give them their
own description (message) as well as source.

By using exceptions, you gain the ability to use structured exception
handling (Try...Catch...Finally), which is the preferred way.
"ad*@message4u.com" <an*******@discussions.microsoft.com> wrote in message
news:01****************************@phx.gbl...

Dear all,

This is more like a theoretical or conceptual question:
which is better, using exception or return code for
a .NET component?

I had created a COM object (using VB6), which uses return
code (not generating error/exception) so it is more
compatible with other programming language.

Now we are migrating the COM object into .NET component
but wondering whether I should change my code to work
with exception instead? How popular is the use of
exception? Is it supported by all .NET-enabled
programming language?

Thanks,
Adi

Hi Scott,

Thank you for your answer. I guess the next question
would be: why is the exception preferred than result
code? Is there any technical reasons behind it? Or is it
just something new or trendy.

What I found out so far is most non-Microsoft language
may not be compatible with exception handling. I guess
it''s old fashion to use return error code, but it seems
to be widely accepted and easier to understood (or maybe
used to it).

I will have to justify the time required to replace the
return code with exception class. So, a good
technical/business perception would be greatly
appreciated.

Regards,
Adi

-----Original Message-----
Exceptions are the way to go. Yes, they are supported across all the .NETlanguages because all the languages support the same class libraries and theException class is in there.

You can create your own custom exceptions as well and then give them theirown description (message) as well as source.

By using exceptions, you gain the ability to use structured exceptionhandling (Try...Catch...Finally), which is the preferred way.

"ad*@message4u.com" <an*******@discussions.microsoft.com> wrote in message
news:02****************************@phx.gbl...

Hi Scott,

Thank you for your answer. I guess the next question
would be: why is the exception preferred than result
code? Is there any technical reasons behind it? Or is it
just something new or trendy.
Not new by any means, just new to VB. Java, JavaScript, C & C++ have used
Structured Exception Handling for some time.

The idea of "Structured Exception Handling" is, well more structured than
the awkward VB "On Error GoTo" or "On Error Resume Next" way.

It looks like this....

Try
''Code that could fail goes here
Catch n as ExceptionType
''Code that should run when the ExceptionType mentioned above is raised
''The name you give to the exception, "n" in this case is used to
represent the exception and
''can therefore be interrogated with standard exception properties
''such as "Message" (like the old VB Description) and Source (which
indicates what assembly threw the exception
Catch n1 as OtherExceptionType
''Ditto the above
Catch n99 as Exception
''Note that the last "Catch" you test for should test for just a plain
"Exception" and not
''any specific type of exception
''This serves as a "Catch All" for any exceptions you didn''t specifically
test for
Finally
''This section is not required but any code in here
''will run whether there is an exception or not
End Try

You can see that there is much more "Structure" to the process using this
method and because many other languages already used this way, it''s a
consistent approach to error handling.

If you caught errors only by codes returned, you wouldn''t be able to use
this method beause, by definition, Structured Exception Handling handles
exception "types" not error codes.

What I found out so far is most non-Microsoft language
may not be compatible with exception handling. I guess
it''s old fashion to use return error code, but it seems
to be widely accepted and easier to understood (or maybe
used to it).
Not true, see my first line of comments.

I will have to justify the time required to replace the
return code with exception class. So, a good
technical/business perception would be greatly
appreciated.
Much more consitent with other languages (Java, JavaScript, C, C++, C# and
more)
More powerfull when working in an OO language (Exceptions are classes and
therefore creating custom exceptions is as simple as creating a new class
that inherits from the base exception class).

Hope this helps!

-Scott

Regards,
Adi

-----Original Message-----
Exceptions are the way to go. Yes, they are supported

across all the .NET

languages because all the languages support the same

class libraries and the

Exception class is in there.

You can create your own custom exceptions as well and

then give them their

own description (message) as well as source.

By using exceptions, you gain the ability to use

structured exception

handling (Try...Catch...Finally), which is the preferred

way.

这篇关于例外与退货代码的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！