构造函数和例外 [英] Constructors And Exceptions
问题描述
我最近在当地书店浏览了几本C ++书籍。
一本名为从构造函数中抛出异常的书可疑的做法。
另一本书建议不要从构造函数中抛出异常，因为
这个正在构造的对象的析构函数不会被执行
而且作为一个结果如果在执行析构函数时取消分配依赖于
，则构造函数在
抛出异常之前分配的任何资源都不会被释放。作者建议设置一个状态
指标，并要求该类的客户甚至
类的成员函数在访问成员之前检查该状态指示器而不是
信号构造函数通过异常机制失败。
我对第一本书的初步反应是，这种做法并不可疑但是
是事实上，一个被C ++社区接受的技术
（包括该语言的创始人）。
我对第二本书的初步反应是如果程序员理解对象构造和破坏的
机制并且知道异常安全
编程技术，例如Meyers，Sutter和其他人教授的那些
它成为处理构造函数失败的一种非常安全的方法。
在不知情的手中危险...也许。
可疑......我不知道。
这些作者是少数吗？
如果其中一个人采访了我，我不确定我是否愿意为
$ b工作$ b他们。当然，因为这些人正在为作者C ++书籍付钱，而且我不会认为他们是知识渊博的C ++程序员:)
我是确保所有处理失败的技巧都适当，并且可以应用这些技术。
我很想知道这个新闻组成员的想法。
===============
Brian Folke Seaberg
=== ============
一个高贵的精神使最小的人拥抱 - Jebediah Springfield
I was recently browsing a couple of C++ books at the local bookstore.
One book called throwing exceptions from constructors a "dubious practice."
Another book recommended not throwing exceptions from constructors due to the
fact that the destructor for the object being constructed will not be executed
and that as a result any resources allocated by the constructor prior to
throwing the exception will not be deallocated if the deallocation is dependent
upon the execution of the destructor. The author suggests setting a status
indicator and requiring clients of the class and even member functions of the
class to examine that status indicator prior to accessing members rather than
signaling constructor failure via the exception mechanism.
My initial reaction to the first book was that the practice is not dubious but
is in fact a technique that is accepted by the C++ community at large
(including the originator of the language.)
My initial reaction to the second book was that if programmers understand the
mechanics of object construction and destruction and knew of exception safe
programming techniques such as those taught by Meyers, Sutter and others that
it becomes a perfectly safe method for handling constructor failure.
Dangerous in the hands of the unknowing...maybe.
Dubious...I don''t know about that.
Are these authors in the minority?
If one of these guys interviewed me I would not be sure I wanted to work for
them. Of course since these guys are being paid to author C++ books and I am
not I will assume they are the more knowledgeable C++ programmers :)
I am sure all techniques for handling failure have appropriate and
inappropriate contexts in which they can be applied.
I am curious to know what the members of this newsgroup think.
===============
Brian Folke Seaberg
===============
"A noble spirit embiggens the smallest man" -- Jebediah Springfield
推荐答案
" Brian Folke Seaberg" <峰; bs ********* @ aol.com>在消息中写道
news：20 *************************** @ mb-m24.aol.com。 ..
"Brian Folke Seaberg" <bs*********@aol.com> wrote in message
news:20***************************@mb-m24.aol.com...
我最近在当地书店浏览了几本C ++书籍。
一本名为从构造函数中抛出异常的书是可疑的实践。 ;
另一本书建议不要抛弃构造函数的异常，因为
事实上构造对象的析构函数将不会被执行
因此，如果解析器在执行析构函数时取消分配，则构造函数在抛出异常之前分配的任何资源都不会被释放。
I was recently browsing a couple of C++ books at the local bookstore.
One book called throwing exceptions from constructors a "dubious
practice."
Another book recommended not throwing exceptions from constructors due to
the
fact that the destructor for the object being constructed will not be
executed
and that as a result any resources allocated by the constructor prior to
throwing the exception will not be deallocated if the deallocation is
dependent
upon the execution of the destructor.
这就是为什么应该避免使用原始指针的原因。使用托管指针将
缓解此问题。
class Sample {
public：
样品（）
{
s_ =新字符[5];
throw;
}
私人：
auto_ptr< char *> S_; //析构函数将释放内存，如果异常
被抛出
};
That is why raw pointers should be avoided. Using a managed pointer will
mitigate this problem.
class Sample {
public:
Sample()
{
s_ = new char[5];
throw;
}
private:
auto_ptr<char *> s_; // destructor will free memory if exception
is thrown
};
* Brian Folke Seaberg：
* Brian Folke Seaberg:
我最近在当地书店浏览了几本C ++书籍。
一本名为从构造函数中抛出异常的书可疑的做法。
>另一本书建议不要从构造函数中抛出异常，因为正在构造的对象的析构函数将不会被执行
因此构造函数在
之前分配的任何资源如果取消分配依赖于执行析构函数，则抛出异常将不会被释放。
作者建议设置状态指示并要求类的客户甚至
类的成员函数在访问成员之前检查该状态指示符，而不是通过异常机制发出信号构造函数失败sm。
I was recently browsing a couple of C++ books at the local bookstore.
One book called throwing exceptions from constructors a "dubious practice."
Another book recommended not throwing exceptions from constructors due to the
fact that the destructor for the object being constructed will not be executed
and that as a result any resources allocated by the constructor prior to
throwing the exception will not be deallocated if the deallocation is dependent
upon the execution of the destructor.
The author suggests setting a status
indicator and requiring clients of the class and even member functions of the
class to examine that status indicator prior to accessing members rather than
signaling constructor failure via the exception mechanism.
这些书是哪些？
只是为了让读这个帖子的人能够远离这些垃圾。
-
答：因为它弄乱了人们通常阅读文字的顺序。
问：为什么会这样是坏事吗？
A：热门发布。
问：usenet和电子邮件中最烦人的是什么？
Which books were those?
Just so that people reading this thread can steer away from such trash.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
" Brian Folke Seaberg" <峰; bs ********* @ aol.com>在消息中写道
news：20 *************************** @ mb-m24.aol.com。 ..
"Brian Folke Seaberg" <bs*********@aol.com> wrote in message
news:20***************************@mb-m24.aol.com...
我最近在本地书店浏览了几本C ++书籍。
你能引用这些标题和作者吗？
一本书叫做构造函数中的异常可疑的
练习。 />另一本书建议不要因为
而从构造函数中抛出异常，因为正在构造的对象的析构函数不会被执行
，结果是构造函数在
如果取消分配是
，则取消执行析构函数时，不会释放抛出异常。作者建议设置一个
状态指示器，并要求该类的客户端甚至是
的成员函数在访问成员之前检查该状态指示符而不是通过异常机制检查构造函数失败的
。
我对第一本书的初步反应是，这种做法并不可疑
但实际上是一种被C ++社区接受的技术
（包括发端人）语言。）
我同意。
我对第二本书的最初反应是，如果程序员理解
对象构造的机制和破坏和了解异常
安全编程技术，例如Meyers，Sutter和其他人教授的那些
，它成为处理构造函数失败的一种非常安全的方法。
我同意这一点。
在不知情的手中危险......也许。
可疑......我我不知道。
愚昧无知的人，是的。
这些作者是少数人吗？
不一定。不幸的是，似乎有更多的C ++
书籍教授可疑的练习以及简单地给出错误的信息，而不是好的。本书评论
在 www.accu.org 是一个很好的从''坏'中过滤掉许多''好''
的方法。
如果其中一个人采访了我，我就不会我确定我想为他们工作
。当然，因为这些人正在为作者C ++书籍付钱而且我不会认为他们是知识渊博的C ++程序员:)
不一定。见上文。
我相信所有处理失败的技术都有适当的和不合适的上下文，可以应用它们。
是的，几乎取决于具体情况。
我很想知道这个新闻组成员的想法。
I was recently browsing a couple of C++ books at the local bookstore.
Could you cite the titles and authors please?
One book called throwing exceptions from constructors a "dubious practice."
Another book recommended not throwing exceptions from constructors due to the fact that the destructor for the object being constructed will not be executed and that as a result any resources allocated by the constructor prior to
throwing the exception will not be deallocated if the deallocation is dependent upon the execution of the destructor. The author suggests setting a status indicator and requiring clients of the class and even member functions of the class to examine that status indicator prior to accessing members rather than signaling constructor failure via the exception mechanism.
My initial reaction to the first book was that the practice is not dubious but is in fact a technique that is accepted by the C++ community at large
(including the originator of the language.)
I agree.
My initial reaction to the second book was that if programmers understand the mechanics of object construction and destruction and knew of exception safe programming techniques such as those taught by Meyers, Sutter and others that it becomes a perfectly safe method for handling constructor failure.
I agree with this.
Dangerous in the hands of the unknowing...maybe.
Dubious...I don''t know about that.
Dubious in the hands of the ignorant, yes.
Are these authors in the minority?
Not necessarily. Unfortunately, there seem to be more C++
books that teach ''dubious'' practice as well give simply
wrong info, than there are ''good'' ones. The book reviews
at www.accu.org are a good way to filter many of the ''good''
from the ''bad''.
If one of these guys interviewed me I would not be sure I wanted to work for them. Of course since these guys are being paid to author C++ books and I am not I will assume they are the more knowledgeable C++ programmers :)
Not necessarily. See above.
I am sure all techniques for handling failure have appropriate and
inappropriate contexts in which they can be applied.
Yes, virtually everthing depends upon context.
I am curious to know what the members of this newsgroup think.
现在你知道我的想法了。 :-)
-Mike
Now you know what *I* think. :-)
-Mike
这篇关于构造函数和例外的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
