Re:这么多子类是个好主意吗? [英] Re: Are so many subclasses such a good idea?

查看:80
本文介绍了Re:这么多子类是个好主意吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

您好

kh***@yahoo.com schrieb:


我注意到标准库有一堆

子类,如std :: bad_alloc,std :: runtime_error

派生自std ::例外。



[...]


但这真的是一个很好的设计实践吗?

std的创建者为不同的情况选择子类

似乎很奇怪。为什么他们不为每种情况创造

方法呢?



??? - 你如何抛出一个/方法/?


如果你想有选择地捕捉到这些错误,那么就没有其他方式可以清除它了。

此外,许多类型都没有伤害。那么问题出在哪里?

Marcel

解决方案

6月12日,4:56 * pm,MarcelMüller< news.5.ma ... @ spamgourmet.com>

写道:


??? - 你通常如何抛出/方法/?



我的意思不是抛出一个方法,而是抛出一个值

在catch部分处理但只是一个类

处理异常,或者更好但只有一个函数。


如果你想有选择地捕获这些错误,那就没有其他

干净的方式。



更清洁:


enum {ERRORCODE_UNHAPPY,...};

try {

if(whatever())

抛出ERRORCODE_UNHAPPY;

}

catch(int e){

error_processing(e);

}


此外,许多类型都不会造成伤害。那问题出在哪里?



有太多的子类掩盖了

的含义。我见过C ++代码,其中包含
3或4个子类。很难猜出更深层次的班级真正做了什么。


kh *** @ yahoo.com 写道:


6月12日,4:56 * pm,MarcelMüller< news。 5.ma ... @ spamgourmet.com>

写道:


> ??? - 你通常如何抛出/方法/?



我的意思不是抛出一个方法,而是抛出一个值

在catch部分处理但是只有一个类

处理异常,或者更好但只有一个函数。


>如果你想有选择地捕获这些错误,那就没有了其他
干净的方式。



更清洁:


enum {ERRORCODE_UNHAPPY,...};

try {

if(whatever())

抛出ERRORCODE_UNHAPPY;

}

catch(int e){

error_processing(e);

}



_selective_捕获错误在哪里?

想想


void f(无效){

尝试{

//一些可能抛出的代码

}

catch(some_exception const& e){

}

}


void g(无效){

尝试{

f();

}

catch( some_other_exception const& e){

...

}

}


重点是:不同的异常可以在调用堆栈中升至

不同的级别。该类型确定使用哪个catch处理程序。


>此外,许多类型都不会造成伤害。那问题出在哪里?



有太多的子类掩盖了

的含义。我见过C ++代码,其中包含
3或4个子类。很难猜出更深层次的班级真正做了什么。



这似乎更多的是文档和命名方案的问题

使用而不是推导的深度。此外,使用标准的

异常类,它们都是相同的(通过

what()方法提供消息)。类型系统仅用于对错误进行分类,并允许

在调用堆栈中捕获正确级别的异常。

最佳


Kai-Uwe Bux


6月12日下午5:49,Kai-Uwe Bux< jkherci ... @ gmx.netwrote:
< blockquote class =post_quotes>
_selective_捕获错误在哪里?



这里:

尝试{

如果(a)

throw( UNHAPPY);

if(b)

throw(UNHAPPIER);

if(c)

throw( UNHAPPIEST);

} catch(int which){

switch(which){

case UNHAPPY:... break;

案例UNHAPPIER:......休息;

案例UNHAPPIEST:......休息;

}

}


重点是:不同的异常可以在调用堆栈中上升到

不同的级别。该类型确定使用哪个catch处理程序。



是的,这加强了C ++的编译时输入,

有些人认为这是C ++的优势。


Hi

kh***@yahoo.com schrieb:

I noticed that the standard library has a bunch of
subclasses like std::bad_alloc, std::runtime_error
that derive from std::exception.

[...]

But is this really a good design practice?
It seems odd that the creators of std chose subclasses
for different situations. Why didn''t they create
methods for each situation instead?

??? - how do you usually throw a /method/ ?

And if you want to catch these errors selectively, there is no other
clean way.
Furthermore that many types don''t harm. So where is the problem?
Marcel

解决方案

On Jun 12, 4:56*pm, Marcel Müller <news.5.ma...@spamgourmet.com>
wrote:

??? - how do you usually throw a /method/ ?

I meant not so much to throw a method, but to throw a value
that in the catch section is handled but just one class
that handles exceptions, or better yet just one function.

And if you want to catch these errors selectively, there is no other
clean way.

Much cleaner:

enum {ERRORCODE_UNHAPPY, ...};
try {
if (whatever())
throw ERRORCODE_UNHAPPY;
}
catch (int e) {
error_processing(e);
}

Furthermore that many types don''t harm. So where is the problem?

Having too many subclasses obscures the meaning of
what''s really going on. I''ve seen C++ code that have
3 or 4 subclasses deep. It''s hard to guess what
the deeper classes really do.


kh***@yahoo.com wrote:

On Jun 12, 4:56*pm, Marcel Müller <news.5.ma...@spamgourmet.com>
wrote:

>??? - how do you usually throw a /method/ ?


I meant not so much to throw a method, but to throw a value
that in the catch section is handled but just one class
that handles exceptions, or better yet just one function.

>And if you want to catch these errors selectively, there is no other
clean way.


Much cleaner:

enum {ERRORCODE_UNHAPPY, ...};
try {
if (whatever())
throw ERRORCODE_UNHAPPY;
}
catch (int e) {
error_processing(e);
}

And where is the _selective_ catching of errors?
Think about

void f ( void ) {
try {
// some code that might throw
}
catch ( some_exception const & e ) {
}
}

void g ( void ) {
try {
f();
}
catch ( some_other_exception const & e ) {
...
}
}

The point is: different exceptions can rise up in the call stack to
different levels. The type determines which catch handler is used.

>Furthermore that many types don''t harm. So where is the problem?


Having too many subclasses obscures the meaning of
what''s really going on. I''ve seen C++ code that have
3 or 4 subclasses deep. It''s hard to guess what
the deeper classes really do.

That seems to be more a problem of documentation and the naming scheme
employed rather than the depth of the derivation. Besides, with standard
exception classes, they all do the same (provide a message by means of the
what() method). The type system is just used to classify errors and allow
to catch exceptions at the right level in the call stack.
Best

Kai-Uwe Bux


On Jun 12, 5:49 pm, Kai-Uwe Bux <jkherci...@gmx.netwrote:

And where is the _selective_ catching of errors?

Here:
try {
if (a)
throw(UNHAPPY);
if (b)
throw(UNHAPPIER);
if (c)
throw(UNHAPPIEST);
} catch (int which) {
switch (which) {
case UNHAPPY: ... break;
case UNHAPPIER: ... break;
case UNHAPPIEST: ... break;
}
}

The point is: different exceptions can rise up in the call stack to
different levels. The type determines which catch handler is used.

True, that reinforces C++''s compile-time typing,
which some consider to be an advantage of C++.


这篇关于Re:这么多子类是个好主意吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆