I'm not necessarily advocating the use of this method to avoid compile-time checking of exceptions, but I think it's important to know that you have this option. It's a bit of a hack, but hey -- if it's good enough for Sun it must be good enough for us, right?Avoiding Checked Exceptions
There is one place in particular where I can see this method being useful. Some Aspect Oriented Programming (AOP) frameworks, such as AspectJ, have support for automatically "softening" exceptions by wrapping them with an unchecked exception. However, this suffers from the same problem that we highlighted above -- the identity of the exception changes after it is wrapped, and therefore it is more difficult to catch the exception at a higher level. It may be interesting to give these frameworks support for using Unsafe.throwException instead.
Another interesting idea is to implement an annotation that softens exceptions in this manner. Using either source-code instrumentation (via apt) or bytecode instrumentation (as I described in my Peeking Inside the Box articles), code could be inserted that would use Unsafe.throwException to soften the exceptions. Unlike the AOP approach, this would make it clear from the source code what is happening.
public void loadData (int objId)
// ...code that throws an SQLException...