송은우·2023년 2월 27일


목록 보기

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


public synchronized Throwable getCause() {
return (cause==this ? null : cause);

추후에 initCause로 초기화 1번 가능

finally 에서 다시 던질 경우

왜 예외는 로직에 포함되면 안될까?
stack 쌓는게 비싸서

이유가 존재하는 이유
1. 상위 계층에 어울리는 예외로 재정의
2. 범용 인터페이스 유지하면서, 예외 던지고 싶을 때

The JVM saves some indication of the stack backtrace in this slot.
private transient Object backtrace;

학생의 마음가짐으로 최선을 다하자

0개의 댓글