흠....
좀 별론가?? 대충 이렇게 쓰면 되는데
딱국(kgm12345)
2024-01-26 23:48
추천 0
댓글 25
다른 게시글
-
중고나라 수사기관이 나 사찰하는데 조사하기 귀찮으니까 차단하는 거발명도둑잡..(aerohong) | 24.01.26추천 0
-
c++ 제네릭 보니까 신기하네 [3]익명(211.209) | 24.01.26추천 0
-
도시가스 독촉장 날라옴 ㅅㅂ [5]익명(211.36) | 24.01.26추천 0
-
중고나라 두번째 차단 당한거 진짜 짜증나네 [2]발명도둑잡..(aerohong) | 24.01.26추천 0
-
금융와라익명(223.62) | 24.01.26추천 0
-
C++ 하나도 모른채로 MFC 할수있음? [2]익명(59.16) | 24.01.26추천 0
-
maria DB 쓰는 애 있냐?익명(220.70) | 24.01.26추천 0
-
금융오지마라 체력 바닥났다 [1]금융오지마..(famous6689) | 24.01.26추천 0
-
잠이 안 온당..♥길잃은아..(re2002) | 24.01.26추천 0
-
연봉 4500만원짜리 직군 업무...jpg [5]익명(1.219) | 24.01.26추천 1
왼쪽이 사용전, 오른쪽이 사용 후
아 별론가.... 그냥 자기만족같기도 하고
아오 필터 이거 참이랑 거짓 반대로 적었네. 왼쪽거 배낀답시고
컨셉자체는 괜찮은것같은데 메세지 부분에서의 확장이 좀 애매하네. 그렇다고 조합에 무조건적으로 용이한것도아니고
메세지 부분의 확장이 무슨뜻이야?
지금 근데 이 예시는 map이 없어서 효용이 거의 없음
filter가 순수하게 필터의 역할만 하는게 아니라 다른 사이드이팩트가 껴있다구
근데 사이드이팩트를 특정 규칙을 만들어서 허용해준거잖어. 그럼 그 규칙이 시간의 변화에 따라서 변화에 용이할것인가 생각해볼 필요가 있을듯. 지금 당장은 잘 동작하겠지만
사이드이펙트 없는데. 저거 Either을 본딴거임
근데 아까 전 글이랑 이 글만 보고 대충 직관으로 추리한거라 정확하지 안흥ㄹ 수 있는데 API결과물에 filter랑 map을 걸어놔서 타입안정성 + 로직안정성 + Optional 지원해준다는건가?
아 그냥 error만 thorw하는거구나. 나는 error handling을 위한 특수 규칙이 있을 줄 알았지
null safety랑 기타 필터 지원함. 그리고 기본적으로는 null safety 때문에 만든건데, 이거 한번 진짜 모든데에다가 죄다 null safety 박아봤다가 코드 좆창나가지고 디비에서 꺼내올때, nullable = false 인 항목들은 그냥 안전하다고 가정하고 쓰기로 결정했음. 그래서 최초목적은 null safety 고, getter 체이닝해갈때 각각 중간단계마다 이프걸고 에러메세지 띄우는거땜에 골치아팠던건데 그 예시가 지금은 별로 없음. 다른 브랜치에있는데 보여줄수있음. 널세이프티는 보통 map으로 처리함
에러 쓰로우 안해. 에러 메세지만 빌드하는거고, 에러메세지 빌드랄것도 없이 최초의 에러메세지만 저장함
이것도 부작용이었는지 기억이 안나는데, map이나 filter에 넣은 람다가 익셉션 반환할경우 ApiException의 경우는 이제까지 성공이었다면 실패메세지랑 상태를 해당 ApiException걸로 만들면서 실패로 바꾸고 그 외 Exception은 로직 바깥으로 튀어나감. 일부러 튀어나가라고 그렇게 했음.
즉, 람다에서 익셉션이 떳고, 그게 ApiException으로 예상한 것들 범주 바깥일 경우에만 바깥으로 튀어나가고 (그래야함. 이거는 내 로직 중단시켜야할 중요한 에러임) 그 외에는 무조건 아무 부작용 없이 ApiOptional 혹은 ApiOptionalList가 순수하게 튀어나옴. 다 final이고 매 단계마다 새로생성함
그리고 이게 맵이 없어서 자꾸 예시가 안들어지는데, filterAll 을 통해서 개별 원소 얻었지? 그 개별원소에 다시 ApiOptional 걸고서 체이닝 하고, 맵핑하고 이러면 검증대상을 자꾸 바꿔나가면서 이어나갈수있음. 이 이어나가는게 이프문으로 힘들었음. 계속 중간중간 끊고 이프 이프 이프 넣어야해서
근데 생각보다 그렇게까지 좋은거같진 않은거같으면서도... 잘 모르겠네... 로직은 엄청 깔끔한데, 너무 장황해.... 하스켈같은거면 그냥 깔끔할텐데
하스켈은 그냥 do 블록 박아버리면 진짜 가독성 엄청좋아서
기능을 떠나서, 굳이 별도 랩퍼를 만든 이유는.. (1) API 데이터 에러 (개발자가 예측한 에러) 처리와 (2) data의 Null safety 보장. 요 두개가 핵심인것같은데.. 꼭 저렇게 풀어야하나 생각중임. (나도 최근에 비슷한거 했었어서 고민중..)
저 두개가 아니라면 그냥 자료구조에 stream을 넣고 처리해도되고 아니면 걍 영속성 계층에서 데이터만 잘 발라주면 되는거자너
이거 거의 자기만족인듯
혼자 작업해야하는 코드 아니라면, 님 부재시에 나중에 팀원들이 이 규칙을 다 뜯어봐야하는게 고통이니까 그런거쥐. 님말대로 장황하다라는 포인트가 생기면 레거시 관리할 때 치명적이라.. 만약 혼자 하는 플젝이면 이런거 해보고 불편한부분 고쳐가도 상관없을듯. 내가 갠적으로 우려되는건 위에서 님이 설명한 문제해결을 위해서 새로운 규칙을 도입했는데, 그 규칙이 정말 모든사람들에게 편하게 받아들여질 수 있는 제약인지가 궁금한듯. 근데 단순히 Optional Wrapper라 모듈 개발만 쉽다면 오히려 유용할것같기도하고..
저 에러부분이 걸리네.. APIExcepti라는것을 쉽게 안정적으로 사용하려면 저 문법을 익혀야된다라는게 걸림.
근데 에러 핸들링이라는게 태생적으로 답이 없기때문에 차라리 님처럼 총대매고 한꼭지에서 대응하게 해두는것도 나쁘지않은것같기도하고.. 고민이당
나는 지금 모든 에러를 다 컨트롤하고있어. 내가 인식 가능한 에러, 이거는 바깥으로 명시해야하는 에러는 전부 메세지 담아서 래핑해줌. 그래서 다른데에서 api를 캐치할일 있을때, 내가 명시한 에러인지 아닌지를 분기하고, 내가 인식하지 못한에러는 그냥 바깥으로 내보냄으로써 이 에러는 무조건 서버에러니까 잡으세요 라던가