ㄹㅇ 제어할수 있는 선에서는 애초에 이상하게 안돌게 해야지 자기 코드안에서 도는건데 try랑 Null처리 덕지덕지 발라놓으면 안되지
익명(223.39)2019-10-09 13:11
답글
이얘기임 IndexOutOfRange를 지코드에서 왜쳐던지냐고 - dc App
익명(175.223)2019-10-09 13:19
ㅇㅇ 그냥 입력값을 충분히 고려하는 모듈하나 만드는게 더 안정성있지
익명(175.113)2019-10-09 13:12
답은 Result
ㅇㄹ(rerereq)2019-10-09 13:13
답글
ㅋㅋㅋㅋㅋㅋㅋㅋ
기괴공학도(mecheng98)2019-10-09 13:14
문제는 에러를 모두 예측할 수 없고, 사용자가 돌리는중에 다운되면 안된다는 사실임.
개발중에는 Try catch 다 끄고, 배포할땐 다 켜고 하는게 딱 맞음.
개발중에는 어디서 에러가 생기는지 알아야 해결을 하지. 굳이 해결할필요 없거나 절대 심각한건 안생길 부분이면 몰라도.
근데 병신같이 개발중에도 아무데나 다 켜놓고 혹은 아예 반대로하는 새끼까지 있더라.
try catch 쓰는 습관 별로 안좋은거야?
아니 내 생각일 뿐임 - dc App
답은 ExceptT이다
잡아서 처리할거 아니면 걍 던져서 끝내는게 맞다며
ㄹㅇ 제어할수 있는 선에서는 애초에 이상하게 안돌게 해야지 자기 코드안에서 도는건데 try랑 Null처리 덕지덕지 발라놓으면 안되지
이얘기임 IndexOutOfRange를 지코드에서 왜쳐던지냐고 - dc App
ㅇㅇ 그냥 입력값을 충분히 고려하는 모듈하나 만드는게 더 안정성있지
답은 Result
ㅋㅋㅋㅋㅋㅋㅋㅋ
문제는 에러를 모두 예측할 수 없고, 사용자가 돌리는중에 다운되면 안된다는 사실임. 개발중에는 Try catch 다 끄고, 배포할땐 다 켜고 하는게 딱 맞음. 개발중에는 어디서 에러가 생기는지 알아야 해결을 하지. 굳이 해결할필요 없거나 절대 심각한건 안생길 부분이면 몰라도. 근데 병신같이 개발중에도 아무데나 다 켜놓고 혹은 아예 반대로하는 새끼까지 있더라.
이말은 일리가 있는듯 - dc App