일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
Tags
- 파이썬
- 단위테스트
- 컴포즈
- rxjava
- 안정성
- UnitTest
- 안드로이드
- Android
- 공격적 프로그래밍
- 디자인패턴
- 코딩테스트
- git
- Di
- MVVM
- 자료구조
- Kotlin
- ViewModel
- Jetpack
- Observable
- 제한함수
- mock
- 유닛테스트
- 테스트의 장점
- Room
- 깃
- 코틀린
- dagger2
- 안드로이드 디자인패턴
- compose
- Python
Archives
- Today
- Total
세상을 바꾸는 개발자
[이펙티브 코틀린] 결과 부족이 발생할 경우 null과 failure를 사용하라 본문
안드로이드는 자바와 코틀린 2가지 언어로 개발을 할 수 있지만 요즘 자바를 사용해서 개발하는 경우는 찾아보기 힘듬니다
저또한 코틀린을 사용합니다 하지만 사용하면서 잘 몰랐던 부분도 있고 한번도 써보지않는 편리고 좋은 기능들이 많이 존재합니다 그래서 이번에 복습할겸 이펙티브 코틀린의 내용으로 정리를 하려고 합니다.
안정성 - 결과 부족이 발생할 경우 null과 failure를 사용하라
함수가 원하지않는 경과랄 만들어내는 경우에 이를 처리하는 2가지 매커니즘
1. null 또는 실패를 나타내는 sealdclass(failure 등) 리턴
2. 예외를 throw 한다 -> 지양해야하는 경우
예외는 정보를 전달하는 방법으로 사용해서는 안된다
- 많은 개발자가 예외가 전파되는 과정을 제대로 추적하지 못한다
- 코틀린의 모든 예외는 unchecked 예외 이다, 따라서 사용자가 예외를 처리하지 않을 수 있다
- 예외는 예외적인 상황을 처리하기 위해서 만들어졌으므로 명시적인 테스트만큼 빠르게 동작하지 않는다
- try - catch 블록 내부에 코드를 배치하면, 컴파일러가 할 수 있는 최적화가 제한 된다
Failure 같은 seald 클래스를 사용하면 예외를 다루기 쉽고 놓치기 어렵다.
null 을 처리해야 한다면, 사용자는 안전호출 또는 elvis 연산자 같은 다양한 널 안정성 기능을 활용한다
val age = useText.readObjectOrNull<Person>()?.age ?: -1
result 와 같은 공용체를 리턴하기로 했다면, when 표현식을 사용해서 이를 처리하면 좋다
val person = useText.readObjectOfNull<Person>()
val age = when(person){
is Success -> person.age
is Failure -> -1
}
checked 예외 : 사용자가 반드시 처리하게 강제되는 예외를
unchecked 예외 : 처리하지 않아도 실행에 문제가 없는 예외
참고 : 이펙티브 코틀린
'안드로이드 > Kotlin' 카테고리의 다른 글
[이펙티브 코틀린] 코틀린의 안정성 - 적절하게 null 을 처리하라 (0) | 2023.07.18 |
---|---|
[이펙티브 코틀린] 방어적 프로그래밍 vs 공격적 프로그래밍 (0) | 2023.07.17 |
[이펙티브 코틀린] 코틀린의 안정성 - 사용자 정의 오류보다는 표준 오류를 사용하라 (0) | 2023.07.15 |
[이펙티브 코틀린] 코틀린의 안정성 - 최대한 플랫폼 타입을 사용하지 말라 (0) | 2023.07.12 |
[이펙티브 코틀린] 코틀린의 안정성 - inferred 타입으로 리턴하지 말라 (0) | 2023.07.12 |
Comments