blocks|key|3945848|text|你会问，|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3945849|3945850|“当构造函数抛出未处理的异常时会发生什么？对于Java，对于C%2B%2B？会不会有内存泄漏？“|blockquote|3945851|3945852|3945853|3945854|在C%2B%2B中，任何未处理的异常都会终止程序。未指定在这种情况下是否展开堆栈，即是否执行成功构造的局部变量的析构函数取决于编译器。异常从哪里抛出(比如在构造函数中)是无关紧要的。|3945855|3945856|如果找不到匹配的处理程序，则调用函数std::terminate()；无论在此std::terminate()调用之前是否展开堆栈都是由实现定义的。|offset|length|style|CODE|3945857|3945858|Java中未处理的异常同样必须终止程序，或者至少终止当前线程(如果它不是主线程)，但要保证调用finally子句：|3945859|3945860|+Java+7语言规范§11.3：|BOLD|3945861|3945862|“如果找不到可以处理异常的catch子句，则终止当前线程(遇到异常的线程)。|3945863|3945864|由于程序终止，因此实际上程序本身不会发生内存泄漏，因为实际上操作系统会在一个进程之后进行清理。|3945865|但是，崩溃的程序可能会在磁盘上留下临时文件，并且可能会泄漏服务器进程的其他资源，包括这些服务器进程中的内存泄漏。|3945866|entityMap^0|0|0|0|0|0|0|0|0|I|G|13|G|0|0|1B|7|0|0|1|F|0|0|D|5|0|0|0|0^^$0|@$1|2|3|4|5|6|7|18|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|19|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|1A|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]|$1|G|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|1E|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|1F|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1G|8|@$N|1H|O|1I|P|Q]|$N|1J|O|1K|P|Q]]|9|@]|A|$]]|$1|R|3|-4|5|6|7|1L|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1M|8|@$N|1N|O|1O|P|Q]]|9|@]|A|$]]|$1|U|3|-4|5|6|7|1P|8|@]|9|@]|A|$]]|$1|V|3|W|5|E|7|1Q|8|@$N|1R|O|1S|P|X]]|9|@]|A|$]]|$1|Y|3|-4|5|6|7|1T|8|@]|9|@]|A|$]]|$1|Z|3|10|5|6|7|1U|8|@$N|1V|O|1W|P|Q]]|9|@]|A|$]]|$1|11|3|-4|5|6|7|1X|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|14|3|15|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|16|3|-4|5|6|7|20|8|@]|9|@]|A|$]]]|17|$]]

You ask,

<blockquote>
 &ldquo;What happens when an unhandled exception is thrown from a constructor? For Java, and for C++? Will there be a memory leak?&rdquo;
</blockquote>

An unhandled exception is an exception that does not have an associated handler.

In C++ any unhandled exception terminates the program. It is unspecified whether the stack is unwound in this case, i.e. destructors of successfully constructed local variables may be executed or not depending on the compiler. Where the exception is throw from (such as inside a constructor) is irrelevant.

<blockquote>
 C++11 §15.3/9: 
 &ldquo;If no matching handler is found, the function <code>std::terminate()</code> is called; whether or not the stack is unwound before this call to <code>std::terminate()</code> is implementation-defined.&rdquo;
</blockquote>

An unhandled exception in Java likewise necessarily terminates the program, or at least the current thread if it&rsquo;s not the main thread, but with guaranteed calls of <code>finally</code> clauses:

<blockquote>
 Java SE 7 Language Specification §11.3: 
 &ldquo;If no <code>catch</code> clause that can handle an exception can be found, then the current thread (the thread that encountered the exception) is terminated. Before termination, all
 <code>finally</code> clauses are executed [&hellip;]&rdquo;
</blockquote>

Since the program terminates there is in practice no memory leak for the program itself, because in practice the operating system cleans up after a process.

However, a crashing program may leave temporary files on disk, and it may leak other resources from server processes, including memory leaks in those server processes.

blocks|key|3945709|text|对于Java:控制流返回给调用者，就像从常规方法抛出异常一样。没有内存泄漏(构造了一半的实例将被丢弃并被垃圾回收)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3945710|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

For Java: Control flow returns to the caller just like with an exception being thrown from a regular method. No memory leak (the half-constructed instance will be discarded and garbage-collected)

blocks|key|165366|text|好吧，至少在C%2B%2B中，一个未处理的异常会一直持续下去，直到它到达你的main()，从而关闭你的程序。未释放的内存将由操作系统处理。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|165367|不确定这是否回答了你的问题...？|165368|所以，基本上，它就像是从其他函数抛出的一样。|165369|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Well, in C++ at least, an unhandled exception would just go on and on until it reaches your main() and thus closes your program. Not freed memory would then be taken care of by the operating system.

Not sure if that answers your question...?

So, basically, it's just like if it was thrown from any other function.

blocks|key|2587699|text|如果您在构造函数内创建依赖对象，则可能会发生内存泄漏。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2587700|在任何语言/环境中，如果这些依赖项被不清理它们的外部实体引用，这可能会导致泄漏。|2587701|在JAVA和C#中，如果依赖项没有被外部引用，这不会导致泄漏。垃圾收集器最终会清理干净。|2587702|在C%2B%2B中，如果依赖项没有被外部引用，这肯定会导致泄漏。|2587703|有关更多可能性，请参阅Jon的答案：Can+constructors+throw+exceptions+in+Java?|offset|length|2587704|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/a/1371559/1037993^0|0|0|0|0|I|16|0|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|U|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|V|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|X|8|@]|9|@$J|Y|K|Z|1|10]]|A|$]]|$1|L|3|-4|5|6|7|11|8|@]|9|@]|A|$]]]|M|$N|$5|O|P|Q|A|$R|S]]]]

You could have a memory leak if you create dependent objects inside the constructor.

In any language/environment this could cause a leak if these dependents are referenced by external entities which don't clean them up.

In JAVA and C# this WILL NOT cause a leak if the dependents are not referenced externally. The garbage collector will eventually clean then up.

In C++ this WILL CERTAINLY cause a leak if the dependents are not referenced externally. 

see Jon' answer for more possibilities: <a href="https://stackoverflow.com/a/1371559/1037993">Can constructors throw exceptions in Java?</a>

blocks|key|3945734|text|值得一提的是：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3945735|1)+Java区分“已检查”和“未检查”异常|3945736|2)大多数用户定义的异常都应该被“检查”。这意味着代码甚至不会编译，除非调用链中的每个模块a)处理异常，或者b)显式标记它可以“抛出”异常|3945737|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

It's worth adding:

1) Java distinguishes between "checked" and "unchecked" exceptions

2) Most user-defined exceptions should be "checked". This means the code won't even compile unless each module in the call chain either a) handles the exception, or b) explicitly marks that it can "throw" the exception

blocks|key|683827|text|对于C%2B%2B，答案在C%2B%2B常见问题解答中。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|683828|How+can+I+handle+a+constructor+that+fails?|offset|length|683829|How+should+I+handle+resources+if+my+constructors+may+throw+exceptions?|683830|来自GOTW的更多信息|683831|entityMap|0|LINK|mutability|MUTABLE|url|http://www.parashift.com/c%2B%2B-faq/ctors-can-throw.html|1|http://www.parashift.com/c%2B%2B-faq/selfcleaning-members.html|2|http://www.gotw.ca/gotw/066.htm^0|0|0|16|0|0|0|1Y|1|0|2|4|2|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@]|9|@$D|X|E|Y|1|Z]]|A|$]]|$1|F|3|G|5|6|7|10|8|@]|9|@$D|11|E|12|1|13]]|A|$]]|$1|H|3|I|5|6|7|14|8|@]|9|@$D|15|E|16|1|17]]|A|$]]|$1|J|3|-4|5|6|7|18|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]|R|$5|M|N|O|A|$P|S]]|T|$5|M|N|O|A|$P|U]]]]

For C++, the answer is in the C++ FAQ.

<a href="http://www.parashift.com/c++-faq/ctors-can-throw.html" rel="nofollow">How can I handle a constructor that fails?</a>

<a href="http://www.parashift.com/c++-faq/selfcleaning-members.html" rel="nofollow">How should I handle resources if my constructors may throw exceptions?</a>

More info from <a href="http://www.gotw.ca/gotw/066.htm" rel="nofollow">GOTW</a>

blocks|key|3945749|text|是否会发生内存泄漏取决于代码的编写方式。如果你写了“好”的代码，你就不应该有内存泄漏。但这完全有可能出现严重错误的情况。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3945750|如果构造函数在构造函数中分配了任何内容，那么很可能会出错。|3945751|一般来说，解决方案是使用所谓的“两阶段构造”，因此构造函数本身非常简单，并且“不会出错”。一旦构造了对象，您就可以调用一个成员函数，该函数以可能失败的方式填充对象，然后您可以随意抛出异常，只要确保析构函数在最后某个时刻运行，一切都应该正常工作。注意“析构函数中的部分构造对象”--如果你的指针是空的，或者其他东西没有在析构函数中途被构造，会发生什么。|3945752|上面的问题是“在我们返回main之前，在某个地方有一个处理程序，我们确实想做一些事情，而不是中止整个程序”。|3945753|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Whether you get a memory leak or not depends on how the code is written. If you write "good" code, you shouldn't have a memory leak. But it's entirely possible to come up with scenarios where this goes horribly wrong. 

If the constructor allocates anything in the constructor, then things may well go wrong. 

The solution, in general is to use what's called "two-phase construction", so the constructor itself is very simple and "can't go wrong". Once the object is constructed, you call a member function that fills in the object in ways that could perhaps fail, and you can then throw exceptions at will, and as long as it's ensured that the destructor is run at some point down the line, all should work out well. Beware of "part-constructed object in destructor" tho' - what happens if your pointers are NULL, or if something else hasn't been constructed partway through the destructor. 

[The above is subject to "there is a handler somewhere before we get back to main, and we do actually want to do something other than abort the entire program"].

blocks|key|165534|text|这种情况在两种语言中都是相似但不同的，无论是C%2B%2B还是Java。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|165535|当抛出异常时，它在堆栈中向上传播，查找处理程序。在C%2B%2B或Java中，它可能永远也找不到，因此会一直回滚到程序的开始和终止。在Java中，有一个检查异常的概念，它强制对异常进行某种类型的处理(如果检查过)。在C%2B%2B中，有一个异常规范的概念，但它是不切实际的(设计不良的)，不应该使用，所以在C%2B%2B中，将所有的异常都视为“未检查的”。|165536|无论异常最终是终止程序还是在抛出异常的上游某个地方被捕获，导致这一点的解开过程才是重要的。如果它最终终止了程序，那么，当操作系统回收内存时，当然不会有内存泄漏。你需要担心的是：|165537|如果异常最终在上游某处得到处理，|165538|在解开过程中会发生内存泄漏；|unordered-list-item|165539|会泄漏其他类型的资源(例如，挂起的数据库操作、网络连接等)。因为如果程序终止，它们将不会被操作系统回收/撤消。|165540|165541|在C%2B%2B中，当堆栈展开发生时，简单地说，保证每个完全构造的堆栈绑定对象(包括正在构造的对象的数据成员或基类实例)将以与创建它们完全相反的顺序立即(即，确定地)销毁。因此，只要所有资源都直接绑定到对象的构造/销毁(也称为"RAII")，在解开过程中就不会有泄漏(内存或其他资源)，因为每个成功获取的资源都将被释放(除非在解开过程中释放资源失败，这是您需要小心处理的)。|165542|在Java中，“堆栈”展开也是以同样的方式进行的，只不过不是立即销毁对象，而是将它们标记为已丢弃(即被垃圾回收)，并最终在将来某个不确定的点销毁。这保证了不会发生内存泄漏，只要垃圾收集器保持足够长的存活时间来完成它的工作，我不确定如果程序因未处理的异常而终止(但在这一点上无关紧要)。Java中的主要问题是其他资源。这些资源必须在finally块中释放。可以保证在解卷期间执行finally块，但是，当然，它们必须包含用于释放分配在相应try块中的资源的代码。只要程序员做好了本职工作，资源就不会泄露。|offset|length|style|CODE|165543|事实上，异常是从构造函数抛出的，这并没有太大的区别，基本规则就是在抛出异常时不泄漏资源的基本规则：|165544|165545|在C%2B%2B中，将每个单独的资源(内存或其他资源)绑定到一个单独的对象，该语言保证其余的资源不会泄漏。这是资源获取是初始化(RAII)习惯用法。|165546|在Java语言中，请确保将每个非内存资源获取写入到它自己的try-block中，该try-block有自己的finally块来释放单个资源。|165547|165548|在这两种情况下，您都必须干净地释放您的资源(不要抛出)。|165549|entityMap^0|0|0|0|0|0|0|0|0|4L|7|58|7|62|3|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|17|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|18|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|19|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|1A|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|1B|8|@]|9|@]|A|$]]|$1|K|3|L|5|J|7|1C|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1E|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1F|8|@$R|1G|S|1H|T|U]|$R|1I|S|1J|T|U]|$R|1K|S|1L|T|U]]|9|@]|A|$]]|$1|V|3|W|5|6|7|1M|8|@]|9|@]|A|$]]|$1|X|3|-4|5|6|7|1N|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|J|7|1O|8|@]|9|@]|A|$]]|$1|10|3|11|5|J|7|1P|8|@]|9|@]|A|$]]|$1|12|3|-4|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|13|3|14|5|6|7|1R|8|@]|9|@]|A|$]]|$1|15|3|-4|5|6|7|1S|8|@]|9|@]|A|$]]]|16|$]]

The situation is similar yet different in both languages, C++ or Java.

When the exception is thrown, it propagates back up the stack, looking for a handler. In C++ or Java, it might never find one and thus unwind all the way back to the start and terminate the program. In Java, there is a concept of checked exceptions which enforce that there will be some kind of handling of the exception (if checked). In C++, there is a concept of exception specification, but it is impractical (ill-designed) and should not be used, so, consider all exceptions as "unchecked" in C++. 

Whether the exception ends up terminating the program or being caught somewhere far up-stream of where it was thrown, the unwinding process leading up to that is what matters. If it ends up terminating the program, then, of course, there are no memory leaks as the OS reclaims the memory. What you have to worry about is:

<ul>
<li>Memory leaks during unwinding if the exception is eventually handled somewhere upstream; and,</li>
<li>Other kinds of resources that could leak (e.g., pending database operations, network connections, etc.) because they won't be reclaimed / undone by the OS if the program terminates.</li>
</ul>

As the stack unwinding occurs, in C++, the guarantee is, simply put, that every stack-bound object that was fully constructed (including the data members or base class instance of an object being constructed) will be destroyed immediately (i.e., deterministically) in the exact reverse order in which they were created. So, as long as all resources are tied directly to the construction / destruction of objects (also called "RAII") there will be no leaks (of memory or other resource) during the unwinding process since every resource successfully acquired will be freed (unless freeing the resource fails during unwinding, which is something you need to handle with care).

In Java, the "stack" unwinding occurs in the same fashion, except that instead of immediately destroying the objects, they are marked as discarded (i.e., to be garbage collected), and eventually destroyed at some indeterminate point in the future. This guarantees no memory leaks, as long as the garbage collector stays alive long enough to do its job, which I'm not sure is guaranteed if the program ends up terminating on an unhandled exception (but it doesn't matter at that point). The main problem in Java are the other resources. These resources must be released in the <code>finally</code> blocks. The <code>finally</code> blocks are guaranteed to be executed during the unwinding, but, of course, they must contain code to release the resource allocated in the corresponding <code>try</code> block. As long as the programmer did his job, resources won't leak.

The fact that the exception is thrown from a constructor really doesn't make much of a difference, and the basic rules are just the same basic rules for not leaking resources when exceptions are thrown:

<ul>
<li>In C++, tie every single resource (memory or otherwise) to a single object, and the language guarantees the rest, no leaks. This is the Resource Acquisition Is Initialization (RAII) idiom.</li>
<li>In Java, make sure the write every single non-memory resource acquisition within its own try-block which has its own finally-block that releases that single resource.</li>
</ul>

In both cases, you must release your resources cleanly (no-throw).

What happens when an unhandled exception is thrown from a constructor? For Java, and for C++? Will there be a memory leak?

what happens when an unhandled exception is thrown from a constructor

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

当构造函数抛出未处理的异常时会发生什么？对于Java，对于C++？会不会有内存泄漏？

问当未处理的异常从构造函数抛出时会发生什么
EN

回答 8

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问当未处理的异常从构造函数抛出时会发生什么EN

回答 8

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问当未处理的异常从构造函数抛出时会发生什么
EN