어떠한 조건이 성립되면 안되는 구간에 assert 체크를 넣으면
개발중에는 assert에서 크래시 나는걸 보고 그걸 고칠수있지만
그걸 못찾고 프로덕션에 올리면 컴파일할때 assert를 안지우면 프로덕션에서 크래시뜨는거니까 그건 그거대로 위험하고
assert를 지우면 실행해선 안되는 상태의 코드를 실행해버리니까 그거 역시도 위험한거 아니냐?
버그를 못찾아내는 경우를 염두할때는
if (! ~~~) return;
이게 나은거같음.
아니면 assert 쓸때는 그 다음에 예외처리도 같이 해주는게 정석인거임? 적어도 오늘 본 코드는 그런거 없었음
해당 댓글은 삭제되었습니다.
의도가 머임? 잘못하면 터지라고?
해당 구간만 보면 assert 조건이 사실인지 보장이 안되는데, 앞 구간(middleware 등)이 assert가 false인 경우를 걸러내줘서 굳이 예외처리를 할 필요가 없을때 쓰는거 같음.
assert는 예외처리하라고 있는게아니라 당연히 참이어야하는 조건이라고 명시하는거임. 이게 틀려서 크래시나면 그냥 좃발자가 코드 잘못짰으니까 고쳐야된다는거임.
레거시 코드에서 종종보이는게 아니라 요즘 좃발자들이 배려가 없는거임
좃바충들이 그냥 익셉션 던져요~ 라고 성의없게 표시하는거보다 assert로 아예 catch못하게 무조건 고칠수밖에없게 만드는게 무조건 나음
더더욱 테스팅 코드 외에는 써서는 안될 함수라는 생각이 드네
크래시 뜨는것 자체를 피하고싶은 입장에서는
디버그할땐 필수지. 어차피 c에서는 릴리즈 빌드할때 코드 생략되니까
그럼 assert랑 예외처리를 같이 쓰는게 맞는거같음. 내가 걱정되는건 assert가 거짓나는 상황을 못찾은 상태로 릴리즈했을때 무슨일이 일어날지. assert가 아예 사라져버리면 실행했으면 안될 구문이 실행되는거잖아.
구현코드에서 한다니까? 당장 c++ std라이브러리에도 도배되있는데? .at은 해당 인덱스가 확정적으로 존재한다는 전제하에 사용하는거라고 표준에 명시되있어서 아웃오브랭지면 그냥 assert띄운다. c는 매모리 직접 접근하니까 저런 멍청한 짓하는게 용납자체가 안됨
만약에 assert 거짓뜨는 상황을 모르는 바보짓을 하고 릴리즈해버리면 원래 실행했으면 안될 부분을 실행하는 리스크를 그냥 가져가겠다는거 맞음?
ㅇㅇ 테스트 똑바로 안한 좃발자 잘못이지