Grokking Functional Programming - 2부 6장

6부 오류처리

 

이 장에서는 다음을 수행하는 방법을 배웁니다.

• null 및 예외 없이 모든 오류를 처리합니다 .
• 모든 코너 케이스가 처리되었는지 확인하십시오.
• 함수 서명에서 가능한 모든 오류를 나타냅니다.
• 다른 가능한 오류가 있는 경우 더 작은 기능에서 더 큰 기능을 구성합니다.
• 사용자에게 친숙하고 설명적인 오류를 반환합니다.

오류 없는 프로그램을 작성하는 방법에는 두 가지가 있습니다. 세 번째 것만 작동합니다.

— Alan Perlis, "프로그래밍에 대한 에피그램"

결론은 오류가 없는 프로그램은 없다는 듯 하다.

 

고차 함수를 사용하여 기본 파서에서 더 복잡한 파서를 생성하는 데 사용되는 "파서 결합기"가 있습니다. FP의 핵심입니다.

 

예외처리가 없는 parseShow 는 순수하지 않은 함수다.

 

TvShow show = parseShow(invalidRawShow);
if(show != null) {
  // do more things with the show
}

매우 나쁜 인체 공학! 비즈니스 논리에 집중하는 대신 우리 기능을 사용하는 개발자는 동작할 수 있는 두 가지 다른 방식에 대해 생각해야 합니다.

Option[A]를 사용한다. Java의 Optional<T> 와 같아보인다.

Option 값 을 사용하려고 하면 None 일 가능성을 처리해야 합니다 . 이 주위에 방법이 없습니다! 이후 장에서 배우게 될 다른 프로그래밍 메커니즘에 대해서도 마찬가지입니다. 지금은 오류 처리만 수행합니다. 일부 경우에만 값을 반환하는 함수를 작성하려는 경우 서명에 표시합니다.

FP에서 오류를 나타내는 것은 오류를 나타내는 불변 값을 반환하는 것을 의미합니다.

Option 을 반환하면 클라이언트(코드 사용자)가 오류 가능성을 처리하도록 강제하는 것입니다! 그들은 None 의 가능성이 있음을 알아야 합니다 .

ㅎㅎ.. 클라이언트 개발자가 스펙을 보고 None에 대해서 처리를 해야한다.

Option유형이 잠재적 오류에 대한 정보를 전달 한다는 것입니다 . 그리고 명시적으로 서명의 일부로 만들어서 수행합니다

Options 만 사용하도록 제한하더라도 정확히 동일한 이점을 얻습니다.

1. 두 서명 모두 거짓말을 하지 않고 반환되는 내용을 알려주며 결과 없이 실패할 수 있음을 알려줍니다.
2. 두 기능 모두 전체 응용 프로그램을 충돌시키지 않으며 가능한 모든 오류가 다른 곳(클라이언트 중 하나에 의해)에서 처리되도록 합니다.

Option 에는 이미 orElse 라는 함수가 있습니다

 

기능적으로 프로그래밍한다는 것은 일반적으로 더 많은 컴파일 오류가 발생한다는 것을 의미

FP에서는 런타임 충돌보다 컴파일 오류를 선호합니다.

 

 None 또는 Some 일 수 있는 Option 으로 작업하고 있습니다 . 따라서 정보 손실 없이 목록 으로 변환할 수 있습니다 . 이것이 Option 에 toList 기능이 내장되어 있는 이유입니다. 호출하면 빈 List ( Option 이 None 인 경우 ) 또는 단일 요소 List ( Some 인 경우)를 얻게 됩니다 .

 

all-or-nothing

반환 값에 오류 세부 정보를 전달해야 합니다.

어떤 것이 실패하면 그 이유를 알고 싶습니다! Option 은 오류를 처리하고 오류에서 복구하는 데 유용하지만 무언가 실패하면 얻을 수 있는 것은 None 뿐입니다 . 따라서 우리는 Option 처럼 작동 하지만 추가로 오류에 대한 특정 정보를 제공하고 전파할 수 있는 무언가가 필요합니다.

None이 발생하는 사유를 알고 싶을때

Either[A, B] A(left) 예외 발생 시 사유 넣기, B(Right) 성공 시 처리할 데이터