[TIL] 99클럽 코테 스터디 34일차 TIL : null check

📖 오늘의 학습

---

JSON의 배열 원소로 null이 온다면

 JSON 파싱을 할 때, 일반적으로 리스트에 `null`값이 들어올거라고 생각을 안한다. 애초에 `null`이라는 값이 없다는 것인데, 없으면 안보내면 되는걸 굳이 보낼 이유가 없다. 그렇기에 대부분 배열 자체가 `null`로 오는 것을 체크하지, 배열 내부의 원소가 `null` 인걸 체크하지 않는다. 일반적인 경우 연산 낭비이기 때문이다.

 

 그런데 `null`이 배열 원소로 온다면? '뭐 `null`이니까 적당히 공백 데이터로 파싱한 뒤 넘어가지겠지' 라고 생각했었는데, 아예 예외를 날려버렸다. 그 이유는 형변환 에러. `null`을 `String`이나 `int`, 혹은 내가 정의한 타입으로 변환할 수 없기에 생기는 예외다. `null`은 그 어떤 타입의 서브타입도 아니기 때문이다.

 

이를 위한 null체크

 웬만하면 null로 들어와도 값을 받을 수 있게 모델 클래스의 모든 필드를 Optional타입으로 선언했는데, 리스트의 경우 리스트 자체가 null로 들어오는 것이 아닌 이상 내부의 값을 형변환 하여 넣기 시작한다. 이 때 내부 원소에 null을 String이든 뭐든 변환하려는 순간 타입 에러로 예외가 발생하게 되고, API 호출 중간에 크래시가 나게 된다.

 

그래서 아래와 같이 꼼꼼하게 모든 경우를 체크해줬다. ▼

class ExampleModel {
  ExampleModel({
    this.id,
    this.hashtagList,
  });

  final int? id;
  final List<String>? hashtagList;

  factory ExampleModel.fromMap(Map<String, dynamic>? json) {
    if (json == null) {
      return MagazineListCellModel();
    }

    return ExampleModel(
      id: json['id'] as int?,
      hashtagList: json['hashtags'] != null && json['hashtags'] is List
          ? List<String>.from((json['hashtags'] as List).map(
              (x) => x != null && x.toString().isNotEmpty ? x.toString() : ""))
          : [], // null이거나 비어있을 경우 빈 리스트로 처리
    );
  }
}

 

(물론 이건 예시다. 필드가 한 10개정도 되는데, 대략 이렇게 체크한다고 해놨다.)

 

🤔 오늘의 회고

---

백엔드를 전적으로 신뢰하면 프로그래밍이 굉장히 편해지게 된다. '타입은 무조건 이렇게 들어올거고, 에러가 발생하면 무조건 이런 메세지가 날아올거고...' 그런데 그렇게 백엔드에게 모든걸 위임해버리면 예외 대체가 전혀 되지 않게 된다. '만약 서버가 죽으면?', '만약 신뢰하던 백엔드가 실수를 하게 되면?' 이런 문제들은 사용자가 많을수록, 다루는 가치가 클 수록 치명적으로 다가온다. 이때 백엔드에게 책임을 물을건가? 그렇기에 예외를 더 확실하게 잡아야한다.

 

 오늘 문제는 단순 분기 문제라... 배울건 없었다.