Rust 에서 Panic! 과 Result 는 둘 다 에러 상태를 표현하고 있는데.. 대체 둘이 무슨 차이일까? 왜 만들어졌을까? (240612)

https://github.com/baksohyeon/100-exercises-to-learn-rust/pull/1

[2024-06-12] chapter 1.0 ~ 2.4 / keyword: integer type, NO Truthy/Falsy concept in Rust, panic! & Error with ROP by baksohyeon

추억 ~ 나도 찾기 어려워서 끌올 

Today I learned

1. the workshop runner ⇨ wr will verify my solution
2. Integers Type is more variant
   4u32 == literal value 4 with type annotation u32
3. declare variable named let
4. In Rust, NOT USE truthy or falsy values. only type bool → Rust's philosophy around type coercion.
5. Panic! VS. Result
   see: https://doc.rust-lang.org/std/macro.panic.html

---

NOTE

When to use Panic! vs Result for error handling system in Rust?

• Panic! is like throw Exception in Node.Js or Java.
  This allows a program to terminate immediately and provide feedback to the caller of the program.
• Result in Err(E) is anticipated runtime failure modes. and must be propagated manually.

---

관련 궁금증: Throwing Error with try - catch statement V.S. Result wrapping with if - else statement

• Searching for the monad concept compared to throwing errors (try-catch statements).

(아래 내용은 한글로 작성함)

코드는 간결하나 Exception이 어디서 발생하고 처리되는지 알기 힘든 try-catch
vs
동작방식 직관적으로 알기 힘들고 코드양은 길더라도 Result 객체로 매핑해서 결과값에 따라 직관적으로 처리가 되는 if-else로 처리하기

후자에 대한 중요성이 왜 대두되었는지, 굳이 필요한가 의문점이 든다.

궁금증 해결

• 이해한 내용:

후자의 방법은 함수형 프로그래밍이며 ROP 스타일.

어? 지금 너 에러 던졋냐? 장난하냐?
그것도 엄밀하게
따지고 보면 너가 명시한 '반환 값' 중 일부 아님? 그 예외 케이스까지 반환 타입 중 하나로 분류해두는게 맞는 것 같은데? 일단 니 던져둔거 다시 갖다놔주길ㅎㅎ :^)
→ 이런 돌.아이 역대급 천재 수학가 감성

고등학교에서 배우는 미분 증명이 틀린말은 아니지만 얼렁뚱땅 아니냐 엄청 따지고 딴지걸다가
입실론-델타 논법 증명 정도로 갖다놔야 더 확실하게 끝장을 내야 만족하는 그런 은은한 광기,

확실히 다른 사람이 쓴 코드를 내가 건들 일이 있을 때라던가 덜 불안할 듯함
그리고 에러 단계적으로 에러 타입 퍼올리는 것 관련 좀 귀찮아지긴하는데 TypeScript 에서는 Effect-TS 사용하면 해결됨.
Rust 는 이걸 언어 자체적으로 구현해둔 것임.

궁금증 관련 개념 정리

1. try-catch 문의 예외 처리의 문제점:
   • 함수의 인터페이스만으로는 예외 발생 여부를 알 수 없음
   • 예외 처리를 위해 함수의 내부 구현을 계속 확인해야 함
   • 코드의 추상화 수준을 낮추고 유지보수를 어렵게 만듦

2. Result 타입의 목적:
   • 함수의 시그니처만으로 예외 발생 가능성을 명시하여 예외 발생 가능성이 있는 함수와 그렇지 않은 함수를 타입 수준에서 구분
   • 예외를 타입 시스템으로 표현
   • 성공과 실패 케이스를 명확히 구분
3. Result 타입의 장점:
   • 함수의 타입 서명만으로 함수의 동작을 완전히 이해할 수 있음
   • 예외 발생 가능성이 있는 함수를 쉽게 구분할 수 있음
   • 불필요한 방어적 테스트 케이스를 줄일 수 있음
4. 함수 설계의 원칙:
   • 함수의 타입은 매개변수와 반환값뿐만 아니라 부수 효과도 포함해야 함
   • 추상화를 통해 내부 구현을 숨기고 인터페이스에 집중할 수 있어야 함
5. 프로그래밍 패러다임의 변화:
   • 예외 처리에서 Result 타입 사용으로의 전환
   • 타입 시스템을 활용한 더 안전하고 예측 가능한 코드 작성

이러한 접근 방식은 함수형 프로그래밍의 원칙과 일치함
협업 시 코드의 안정성, 가독성, 유지보수성을 향상함.
Result 타입의 사용은 예외 처리의 복잡성을 줄이고 타입 시스템을 통해 오류를 더 효과적으로 관리할 수 있게 해준다.

---

마무리

이번 진도까지의 내 생각 정리

• 함수형이 요즘 진짜 핫하긴한가보다.
• 실제 내 경험 중에서의 기술적 고찰:
  • 실제로 내가 작업했던 서버 중 가장 인상 깊었던 레포가 함수형 프로그래밍 기법을 적극 도입하고 모나드로 에러 케이스 처리해둔 Nest.Js 서버였다. (전임자분이 2024년 기준 4년전에 작업해둔 커밋이었는데, 대단..ㄷ)

당시에 신기해서 관련 PR에서의 논의 내용과 언급된 관련 개념을 찾아봤었다.
이렇게 다시 마주할줄 몰랐음.

• 당시의 초기 의문:
  • "기존 Nest.Js Life cycle 까지 뒤틀면서 쓸만큼으로 효용성이 있는 것 같지는 않은데, try catch 문으로 처리하는게 분명 단점도 있겠지만, 테스트 코드를 잘 작성한다면 충분히 상쇄할 수 있지 않나?"
• 현재:
  • "아무리 봐도 테케 유무와 상관없이, 논리적으로는 후자의 방식으로 에러 처리하는게 제일 합당하다. 근데 인간이 문제일 것 같다. 만약 코드를 작성할 때 대충 얼렁뚱땅으로 돌아만가라~ 마인드로 구현하는 상황과 같은 경우, 굉장히 귀찮고 거슬려할 것 같은데 이 부분은 내가 직접 써봐야 알 것 같다."

rust 가 나름 자기만의 확고한 철학이 있고 제시사항이 굉장히 설득력이 있는 언어라고 생각함
Panic! 이 친구는 Rust 이 친구랑 계속 같이 가다보면 또 다시 만날 것 같은 지독한 친구같다 딱 삘 옴.
그래도 일단 여기까지 마무리하고 진도 나가고 나중에 복습하고 그 다음에 여기 글 다듬고 블로그에다 포스팅 ㄱ

Last updated at (2024/07/04)

---

참고 자료

• 모나드 개념 https://adambennett.dev/2020/05/the-result-monad/