[%] 근데 exception은 뭐가 날아올지 어떻게 앏?

[익명(112.217)]

타입으로 명시되거나 하는게 아니니까 알 수 없잖아

문서 없으면 ㅈ망이고 있어도 불편하긴 불편할듯

[fender(mysticfall)]

1) 체크드 예외가 있는 언어 - 아마 자바 밖에 없겠지만 - 에선 이는 API 시그네쳐의 일부로 이해함 (자바 같은 경우 실제 Javadoc에도 포함) 2) 그렇지 않은 경우 보통은 타입을 나누어 잡는 경우가 흔하지 않음. 예컨대 웹 시스템이라면 플랫폼의 'catch-all' 예외 처리 코드가 알아서 하게 놔두면 될 문제이고, 이 경우에도 예외의 타입은 디버깅에 유용함.

[fender(mysticfall)]

참고로 예외 있는 언어에서 의미있는 동작 - 사용자에게 예외를 표시, 다른 값으로 recover 등 - 을 하는 게 아니라면 쓸데없이 예외를 잡는 건 일반적으로 안티 패턴으로 본다.

[ns(qwer2357)]

제대로 해주려면 코드에서 뭐 던지는지 다 명시해줘야지. 근데 그건 리턴값(-1, -2같은..) 역시 undocumented면 모르긴 매한가지잖아.

[익명(112.217)]

c++ 경우에 return은 enum 같은걸로 이름 붙여줄 수 있잖아

[ns(qwer2357)]

아니 뭐 enum이라 치면 결국 그것도 뭐를 돌려주는지 아는거잖아? 너가 Custom Library Foo를 제작하고 그게 모두 FooException으로부터 파생되면 뭘 던져도 FooException만 잡으면 될텐데, 걔에다가 Enum code 박는거랑 리턴값에 Enum code두는 사이에 복잡성이 차이가 있을까?

[익명(112.217)]

Foo 라이브러리의 특정 함수가 FooException 중 어떤걸 던질지 모른다는거지. 다 잡으면 되긴 하지만.

[fender(mysticfall)]

예외 코드를 던진다고 호출자가 반드시 일일이 값마다 switch/if else분기해야 하는 이유가 있는 건 아니잖아. 똑같은 거임.

[Adenosie(adenosie)]

보통 api 문서에 예외 뭐던지는지 다나와있을텐데