One legitimate use case for Throwable.fillInStackTrace() is for non-local control flow:
For example, within my TrueZIP framework, I use a complex chain of decorators for file system controllers. One of the controllers in this chain is an instance of the class FsLockController. This object is responsible for managing a ReentrantReadWriteLock for the file system. Now a file system controller somewhere deeper in this chain might detect that a write-lock is required, but only a read-lock has been acquired by the FsLockController. Because you can't upgrade a read-lock to a write-lock without dead-locking, an exception must get thrown, which happens to be an instance of the class FsNeedsWriteLockException. The decorating FsLockController will then catch this exception, release the read-lock and acquire the write-lock before retrying the operation again.
This kind of non-local control flow works actually very well, but there is one thing to consider: Throwing and catching an exception is cheap, but filling in or examining its stack trace is expensive. Now because this particular exception type is solely thrown and catched within this file system controller chain, I do not need a stack trace at all and so I can safely override Throwable.fillInStackTrace() with an empty method body in order to suppress this expensive operation.
Source code for the base class of this exception type can be seen here.
answered 2012-03-29T21:39:46.930