Throwable.addSuppressed error conditions -- use the exception as the cause? (original) (raw)
Steven Schlansker stevenschlansker at gmail.com
Fri Apr 12 23:30:57 UTC 2013
- Previous message: Throwable.addSuppressed error conditions -- use the exception as the cause?
- Next message: Throwable.addSuppressed error conditions -- use the exception as the cause?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Apr 11, 2013, at 9:04 PM, Zhong Yu <zhong.j.yu at gmail.com> wrote:
On Tue, Apr 9, 2013 at 11:54 AM, Steven Schlansker <stevenschlansker at gmail.com> wrote:
I agree, but there is (library) code out there that does this -- the code that caused the problem wasn't even mine. The library should be told to fix the bug. It is really serious, for example, more and more suppressed exceptions can be added to this reused/shared/cached exception, causing memory leak. A mutable exception simply cannot be shared, otherwise there will be multiple exception handler trying to mutate it.
I don't disagree. I only claim that the current state of things makes diagnosis very hard -- the throw site is lost, so you do not even know where the problem is. This needlessly complicates life, and can be caused in the wild by code that long predates Java 7, just by using the new try-with-resources construct. The "action at a distance" is what is painful.
- Previous message: Throwable.addSuppressed error conditions -- use the exception as the cause?
- Next message: Throwable.addSuppressed error conditions -- use the exception as the cause?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]