- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
In case of an exception, traffic is started but only stdout will be saturated
Edit Admin
I've never even heard of the
Thread.destroy()method in Java before. Apparently the Javadoc says that it was never implemented! So that line of code is certainly useless, and ifThread.destroy()had been implemented, there would be an extreme risk of deadlock here—if the thread had held any locks when it was being destroyed, those locks wouldn't ever get released.Edit Admin
That Thread.destroy() call is worse than useless. According to the Javadoc, it always throws a NoSuchMethodError! Luckily, NoSuchMethodError extends Error rather than Exception, so that catch block doesn't catch it, so there's no infinite loop. It still means that a second thread will never be created though.
Edit Admin
Wait. You can throw something that isn't catchable in Java???
Edit Admin
I assume you can catch it, you just have to be explicit with
catch (Error e).Python also has some error types that aren't subtypes of
Exception.Edit Admin
Yeah,
catch (Error e)would work for catching Errors but not Exceptions. You can also docatch (Throwable e)for catching both Errors and Exceptions. Generally, things that you shouldn't normally be trying to catch extend Error so that people don't accidentally catch them and ignore them.Admin
Thread.destroy() has been deprecated for removal since at least Java 8, and was actually removed in Java 11. Here's a link to its documentation from Java 10: https://docs.oracle.com/javase/10/docs/api/java/lang/Thread.html#destroy()
Edit Admin
Oh, is this a workaround for the whole checked exception design flaw?
Edit Admin
No, the workaround for that is RuntimeException, which is a subclass of Exception. RuntimeException and anything that extends it will not be checked at compile time, so you don't need to declare them in your method signatures (though you can anyway, if you want to).