throwable 자기 자신 이유라면 unset
왜 serializable 을 구현했는지
null 메시지 허용
nonexistent or unknown
일때만
enable suppression
writable StackTrace
If suppression is disabled, getSuppressed for this object will return a zero-length array and calls to addSuppressed that would otherwise append an exception to the suppressed list will have no effect.
Subclasses of Throwable should document any conditions under which suppression is disabled and document conditions under which the stack trace is not writable. Disabling of suppression should only occur in exceptional circumstances where special requirements exist, such as a virtual machine reusing exception objects under low-memory situations. Circumstances where a given exception object is repeatedly caught and rethrown, such as to implement control flow between two sub-systems, is another situation where immutable throwable objects would be appropriate
getLocalizedMessage
public synchronized Throwable getCause() {
return (cause==this ? null : cause);
}
추후에 initCause로 초기화 1번 가능
https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=sthwin&logNo=221954943179
finally 에서 다시 던질 경우
왜 예외는 로직에 포함되면 안될까?
stack 쌓는게 비싸서
이유가 존재하는 이유
1. 상위 계층에 어울리는 예외로 재정의
2. 범용 인터페이스 유지하면서, 예외 던지고 싶을 때
The JVM saves some indication of the stack backtrace in this slot.
private transient Object backtrace;
