1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
2 <html lang="en">
3 <head>
4 <title>Java Thread Primitive Deprecation</title>
5 <link rel="stylesheet" type="text/css" href="../../../stylesheet.css" title="Style">
6 </head>
7 <body>
8 <h2>Java Thread Primitive Deprecation</h2>
9 <hr size="3" noshade="noshade" />
10 <h3>Why is <code>Thread.stop</code> deprecated?</h3>
11 <p>Because it is inherently unsafe. Stopping a thread causes it to
12 unlock all the monitors that it has locked. (The monitors are
13 unlocked as the <code>ThreadDeath</code> exception propagates up
14 the stack.) If any of the objects previously protected by these
15 monitors were in an inconsistent state, other threads may now view
16 these objects in an inconsistent state. Such objects are said to be
17 <i>damaged</i>. When threads operate on damaged objects, arbitrary
18 behavior can result. This behavior may be subtle and difficult to
19 detect, or it may be pronounced. Unlike other unchecked exceptions,
20 <code>ThreadDeath</code> kills threads silently; thus, the user has
21 no warning that his program may be corrupted. The corruption can
22 manifest itself at any time after the actual damage occurs, even
23 hours or days in the future.</p>
24 <hr />
25 <h3>Couldn't I just catch the <code>ThreadDeath</code> exception
26 and fix the damaged object?</h3>
27 <p>In theory, perhaps, but it would <em>vastly</em> complicate the
28 task of writing correct multithreaded code. The task would be
29 nearly insurmountable for two reasons:</p>
30 <ol>
31 <li>A thread can throw a <code>ThreadDeath</code> exception
32 <i>almost anywhere</i>. All synchronized methods and blocks would
33 have to be studied in great detail, with this in mind.</li>
34 <li>A thread can throw a second <code>ThreadDeath</code> exception
35 while cleaning up from the first (in the <code>catch</code> or
36 <code>finally</code> clause). Cleanup would have to repeated till
37 it succeeded. The code to ensure this would be quite complex.</li>
38 </ol>
39 In sum, it just isn't practical.
40 <hr />
41 <h3>What about <code>Thread.stop(Throwable)</code>?</h3>
42 <p>In addition to all of the problems noted above, this method may
43 be used to generate exceptions that its target thread is unprepared
44 to handle (including checked exceptions that the thread could not
45 possibly throw, were it not for this method). For example, the
46 following method is behaviorally identical to Java's
47 <code>throw</code> operation, but circumvents the compiler's
48 attempts to guarantee that the calling method has declared all of
49 the checked exceptions that it may throw:</p>
50 <pre>
51 static void sneakyThrow(Throwable t) {
52 Thread.currentThread().stop(t);
53 }
54 </pre>
55 <hr />
56 <h3>What should I use instead of <code>Thread.stop</code>?</h3>
|
1 <!--
2 Copyright (c) 2005, 2017, Oracle and/or its affiliates. All rights reserved.
3 DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
4
5 This code is free software; you can redistribute it and/or modify it
6 under the terms of the GNU General Public License version 2 only, as
7 published by the Free Software Foundation. Oracle designates this
8 particular file as subject to the "Classpath" exception as provided
9 by Oracle in the LICENSE file that accompanied this code.
10
11 This code is distributed in the hope that it will be useful, but WITHOUT
12 ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
13 FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
14 version 2 for more details (a copy is included in the LICENSE file that
15 accompanied this code).
16
17 You should have received a copy of the GNU General Public License version
18 2 along with this work; if not, write to the Free Software Foundation,
19 Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
20
21 Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
22 or visit www.oracle.com if you need additional information or have any
23 questions.
24 -->
25 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
26 <html lang="en">
27 <head>
28 <title>Java Thread Primitive Deprecation</title>
29 <link rel="stylesheet" type="text/css" href="../../../stylesheet.css" title="Style">
30 </head>
31 <body>
32 <h2>Java Thread Primitive Deprecation</h2>
33 <hr size="3" noshade="noshade" />
34 <h3>Why is <code>Thread.stop</code> deprecated?</h3>
35 <p>Because it is inherently unsafe. Stopping a thread causes it to
36 unlock all the monitors that it has locked. (The monitors are
37 unlocked as the <code>ThreadDeath</code> exception propagates up
38 the stack.) If any of the objects previously protected by these
39 monitors were in an inconsistent state, other threads may now view
40 these objects in an inconsistent state. Such objects are said to be
41 <i>damaged</i>. When threads operate on damaged objects, arbitrary
42 behavior can result. This behavior may be subtle and difficult to
43 detect, or it may be pronounced. Unlike other unchecked exceptions,
44 <code>ThreadDeath</code> kills threads silently; thus, the user has
45 no warning that his program may be corrupted. The corruption can
46 manifest itself at any time after the actual damage occurs, even
47 hours or days in the future.</p>
48 <hr />
49 <h3>Couldn't I just catch the <code>ThreadDeath</code> exception
50 and fix the damaged object?</h3>
51 <p>In theory, perhaps, but it would <em>vastly</em> complicate the
52 task of writing correct multithreaded code. The task would be
53 nearly insurmountable for two reasons:</p>
54 <ol>
55 <li>A thread can throw a <code>ThreadDeath</code> exception
56 <i>almost anywhere</i>. All synchronized methods and blocks would
57 have to be studied in great detail, with this in mind.</li>
58 <li>A thread can throw a second <code>ThreadDeath</code> exception
59 while cleaning up from the first (in the <code>catch</code> or
60 <code>finally</code> clause). Cleanup would have to be repeated till
61 it succeeded. The code to ensure this would be quite complex.</li>
62 </ol>
63 In sum, it just isn't practical.
64 <hr />
65 <h3>What about <code>Thread.stop(Throwable)</code>?</h3>
66 <p>In addition to all of the problems noted above, this method may
67 be used to generate exceptions that its target thread is unprepared
68 to handle (including checked exceptions that the thread could not
69 possibly throw, were it not for this method). For example, the
70 following method is behaviorally identical to Java's
71 <code>throw</code> operation, but circumvents the compiler's
72 attempts to guarantee that the calling method has declared all of
73 the checked exceptions that it may throw:</p>
74 <pre>
75 static void sneakyThrow(Throwable t) {
76 Thread.currentThread().stop(t);
77 }
78 </pre>
79 <hr />
80 <h3>What should I use instead of <code>Thread.stop</code>?</h3>
|