Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Digest] 4챕터 정리 + effective java 예외파트 간단 정리 #9

Open
joomanzi opened this issue Jan 29, 2020 · 4 comments
Open
Labels
Digest This issue is about digest

Comments

@joomanzi
Copy link

joomanzi commented Jan 29, 2020

Digest

catch문을 작성하면서 아래와 같은 질문을 스스로 던지자

복구해야하나?
다른 곳에서 처리해야하나?

if 다른 곳에서 처리해야하면:
받는 쪽에서 에러만 보더라도 어떤 상황인지 알도록 잘~ 알려주자

Reason

4장에서 제가 공부하며 좋았던 점은, 그라운드 룰을 제시했다는 점이라 해당 내용 간단히 정리하겠습니다.
학습 정리겸 상기할 겸 남기겠습니다.

Ground rule

1. 발생한 예외를 처리하지 않는 것은, 무시하고 진행하는 것보다 훨씬 나쁜 일이다.

2. 모든 예외는 적절하게 복구되거나, 개발자에게 통보되어야 한다.

3. 무책임한 throws는 적절한 처리로 복구될 기회를 없앤다.

4. 예외 처리 방법에는 세가지가 있다; 1)예외 복구, 2)예외처리 회피, 3) 예외 전환

  1. 예외 복구: 예외 상황에 문제를 해결하고 정상 상태로 돌려 놓는 것.
  • external resource를 사용하는 경우 에러 생길 시 초기상태로 복구(내 의견)
  1. 예외처리 회피: 자신이 예외를 처리하지 않는 것. 예외를 복구하는 것처럼 의도가 분명해야한다.
  • 다른 오브젝트에서 예외처리 책임을 분명히 하거나,
  • 다른 곳에서 다루는 게 최선인게 확실할 때
  1. 예외 전환: 예외회피의 일종, 적절한 예외로 전환 시키는 것
  • 내부에서 발생한 예외를 그것이 던지는 것이 적절한 의미를 부여하지 못할 때
  • 처리하기 쉽고 단순하게 만들기 위해(JAVA언어에서 unchecked, checked 때문에 이런 말이 나온 것 같음)

effective java 9장 예외

1. 예외는 예외적인 상황에만 사용하라

  • 잘 설계된 API는 클라이언트에게 평상시 제어 흐름의 일부로 예외를 사용하도록 강요하면 안된다.

2. 복구가능 상태에는 checked error 사용하고, 프로그래밍 오류에는 runtime exception를 사용하라

  • unchecked 에러는 catch로 처리할 필요가 없으며, 일반적으로 처리해서도 안된다.(복구 불가능하다는 뜻이므로 처리X)
  • 프로그래밍 오류 === 선행조건 위반을 의미

3. 불필요한 checked 예외 사용을 피하라

  • 개발자에게 짐이다

4. 표준 예외를 사용하라

  • 가독성이 높아지고, 배우고 쉽고 사용이 편리해진다.
  • 예외가 발생한 상황을 좀 더 자세히 설명하는 정보를 추가할 필요가 있을 때는 예외클래스 작성 가능

5. 추상화 수준에 맞는 예외를 던져라

  • 하위계층에서 예외를 던질 때 상위 계층 추상화 수준에 맞는 예외로 바꿔서 던져라
  • 제일 좋은 방법은 전환하지 말고 맡은 레이어에서 처리하는 것

6. 메서드에서 던져지는 모든 예외에 대해서 문서를 남겨라

7. 어떤 오류인지 드러내는 정보를 상세하게 담으라

8. 실패원자성 달성을 위해 노력하라

  • 방법1) 실패 가능성 있는 코드를 전부 객체 상태를 코드 앞에 배치한다. (validation 같은 것)
  • 방법2) temp떠서 수정하고 그걸 반영하는 것
  • 노력하라! 라는 말은 트레이드오프가 있는 경우에는 하지말란 것.

9. 예외를 무시하지마라

@joomanzi joomanzi added the Digest This issue is about digest label Jan 29, 2020
@hihiboss
Copy link
Member

3. 불필요한 점검지정 예외 사용을 피하라
  - 개발자에게 짐이다

이 부분은 어떤 뜻인가요?!

@joomanzi
Copy link
Author

joomanzi commented Jan 30, 2020

3. 불필요한 점검지정 예외 사용을 피하라
  - 개발자에게 짐이다

이 부분은 어떤 뜻인가요?!

점검지정이(checked error)인데요 자바 문법 상 해당 에러를 api상에서 던지게 설계를 하면
클라이언트가 항상 해당 에러를 핸들링 해야하는 귀찮음이 생긴다는 뜻입니다!

토비 책에서 언급한 unchecked error를 리턴하는 이유와 같은 맥락입니다!

  • checked 에러로 수정했습니다. 번역본이라 영어로 다시 바꾸면서 작성하다가 빼먹었네요

@ttkmw
Copy link

ttkmw commented Jan 30, 2020

정리 감사합니다!

  1. 추상화 수준에 맞는 예외를 던져라
    하위계층에서 예외를 던질 때 상위 계층 추상화 수준에 맞는 예외로 바꿔서 던져라
    제일 좋은 방법은 전환하지 말고 맡은 레이어에서 처리하는 것

전 이 부분에서 웬만하면 전환하지 말라는 부분이 인상적이었습니다.
이건 예를들어 mvc패턴이면, 컨트롤러에서 발생한 에러를 view쪽으로 전환해서 넘기지 말고 컨트롤러에서 해결하라는 말이겠죠?

@joomanzi
Copy link
Author

joomanzi commented Feb 2, 2020

정리 감사합니다!

  1. 추상화 수준에 맞는 예외를 던져라
    하위계층에서 예외를 던질 때 상위 계층 추상화 수준에 맞는 예외로 바꿔서 던져라
    제일 좋은 방법은 전환하지 말고 맡은 레이어에서 처리하는 것

전 이 부분에서 웬만하면 전환하지 말라는 부분이 인상적이었습니다.
이건 예를들어 mvc패턴이면, 컨트롤러에서 발생한 에러를 view쪽으로 전환해서 넘기지 말고 컨트롤러에서 해결하라는 말이겠죠?

맞습니다! ㅎㅎ

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Digest This issue is about digest
Projects
None yet
Development

No branches or pull requests

3 participants