Worthless features of Java - You really know

When you first learn to develop you see overly broad statements about different features to be bad, for design, performance, clarity, maintainability, it feels like a hack, or they just don't like it.

In this post, I look at some of the feature people like to hate and why I think that used correctly, they should be a force for good.  Features are not as yes/no, good/bad as many like to believe.

Checked Exceptions

I am often surprised at the degree that developers don't like to think about error handling.  New developers don't even like to read error messages. It's hard work, and they complain the application crashed, "it's not working". They have no idea why the exception was thrown when often the error message and stack dump tell them exactly what went wrong if they could only see the clues. When I write out stack traces for tracing purposes, many just see the log shaped like a crash when there was no error.   Reading error messages is a skill and at first it can be overwhelming.

Similarly, handling exceptions in a useful manner is too often avoided.  I have no idea what to do with this exception, I would rather either log the exception and pretend it didn't happen or just blow up and let the operations people or to the GUI user, who have the least ability to deal the error.

Many experienced developers hate checked exceptions as a result.  However, the more I hear this, the more I am glad Java has checked exception as I am convinced they really will find it too easy ignore the exceptions and just let the application die if they are not annoyed by them.

Checked exceptions can be overused of course.  The question should be when throwing a checked exception; do I want to annoy the developer calling the code by forcing them to think a little bit about error handling? If the answer is yes, throw a checked exception.

Was Thread.currentThread().stop(e) unsafe?

The method Thread.stop(Throwable) was unsafe when it could cause another thread to trigger an exception in a random section of code.  This could be a checked exception in a portion of code which didn't expect it, or throw an exception which is caught in some portions of the thread but not others leaving you with no idea what it would do. 

However, the main reason it was unsafe is that it could leave atomic operations in as synchronized of locked section of code in an inconsistent state corrupting the memory in subtle and untestable ways.
To add to the confusion, the stack trace of the Throwable didn't match the stack trace of the thread where the exception was actually thrown.

But what about Thread.currentThread().stop(e)?  This triggers the current thread to throw an exception on the current line.  This is no worse than just using throw exception you are performing an operation the compiler can't check. 

These are only two worthless features but if you want to read full and detail then check Geek On Java - Hub for Android and Java