우테코 프리코스를 진행하면서 다음과 같은 요구사항이 존재했다.
사용자가 잘못된 값을 입력한 경우 throw문을 사용해 예외를 발생시킨후 애플리케이션은 종료되어야 한다.
throw..?? 이번에 처음 보는 친구였기 때문에 이 기회를 삼아 학습해보기로 했다!
예외처리
throw를 배우기에 앞서 try, catch, finally에 대해 알아보자.
예외(exception) 란 실행 중인 프로그램에서 예기치 못한 상황이 발생하여 더 이상 진행할 수 없는 상황을 말한다. 매우 대표적으로는 SyntaxError나 TypeError 등이 있다.
예외가 발생하면 프로그램을 실행할 수 없기 때문에 예외를 처리할 수 있는 방법을 마련해야 한다.
이런 예외처리는 try-catch 문을 사용하여 처리할 수 있다.
try
try는 에러가 날수도 있는 코드를 담은 것이다.
해당 블록안에 있는 코드를 실행하여 에러가 발생한다면 catch 블록으로 옮겨가고, 에러가 발생하지 않는다면 정상적으로 실행된다.
예외는 throw나 예외를 발생시키는 메서드에 의해 발생된다.
catch
해당 블록은 try 블록에서 예외가 발생한 경우에만 실행된다.
에러에 대한 정보를 담은 객체(매개변수)를 사용할 수 있다.
catch 블록에서는 예외를 처리하거나, 예외를 무시하거나 (아무것도 하지 않음), throw 를 사용하여 예외를 다시 발생시킬 수 있다.
e.name : 에러 이름e.message : 에러 상세 내용을 담고 있는 메시지e.stack : 현재 호출 스택. 에러를 유발한 중첩 호출들의 순서 정보를 가진 문자열이다. 디버깅을 목적으로 사용한다.
finally
try 블록에서 일어난 일에 상관없이 해당 블록에 있는 코드는 무조건 실행된다. 따라서 try 블록이 어떤 형태로든 종료되면 실행된다.
return, break, continue등으로 코드의 실행 흐름이 즉시 이동되더라도 무조건 실행된다.
에러가 발생하지 않은 경우: try - finally
에러가 발생한 경우: try - 에러발생 - catch - finally
try 블록이 종료되는 상황
- 정상적으로 블록의 끝에 도달했을 때
- break, continue 또는 return 문에 의해서
- 예외가 발생했지만 catch 절에서 처리했을 때
- 예외가 발생했고 그것이 잡히지 않은 채 퍼져나갈 때
예외 던지기 (throw)
개발자가 직접 에러를 유발시킨다. 에러나 예외 상황을 알리기 위해서이다.
따라서 예외를 강제로 발생시켜야 할 경우에는 throw를 사용한다. 이를 예외 던지기라고 한다.
개발자가 예외를 던지면, 예외 객체가 생성되고, 이 객체는 프로그램 실행 중에 catch 블록에서 처리된다.
예외를 던질 때는 new Error('에러 메세지') 와 같이 예외 객체를 생성하여 던진다.
try {
const even = parseInt(prompt('짝수를 입력하세요'));
if (even % 2 !== 0) {
throw new Error('짝수가 아닙니다.');
}
} catch (e) {
alert(e.message);
}
// 홀수를 입력할 경우
// Error: 짝수가 아닙니다.
참고
자바스크립트의 예외 처리(Exception)
자바스크립트 예외처리
1주차 프리코스 미션을 진행하기 전에 처음 보는 파일이 있어서 확인했더니 이상한(?) engine-strict = true 한줄 코드가 적혀있었다. 그래서 정체를 알아보기 위해서 서칭해보았다.
.npmrc?
npmrc 파일은 npm에서 설정을 저장해두는 파일이다.
우테코 프리코스에서는 npmrc 파일을 통해 node와 npm의 버전을 제한하기 위해서 사용했다.
버전 제한하기
- .npmrc 파일에 다음과 같이 코드 작성
engine-strict = true
- package.json에 engines 속성 추가
"engines": {
"npm": ">=9.6.7",
"node": ">=18.17.1"
}
까지 하면 끝..!
package.json
package.json에 작성한 코드를 살펴보자
"engines": {
"npm": ">=9.6.7",
"node": ">=18.17.1"
}
"engines"는 프로젝트가 동작할 때 필요한 실행 환경의 버전을 지정한다.
"npm": ">=9.6.7"는 프로젝트가 사용해야 하는 npm 버전을 지정한다. ">=9.6.7"는 최소한 9.6.7 버전 이상이어야 한다는 것이다.
"node": ">=18.17.1"프로젝트가 실행될 때 필요한 Node.js 버전을 지정한다. ">=18.17.1"은 최소한 18.17.1 버전 이상이어야 한다는 것이다.
위 코드를 통해 프로젝트가 필요로 하는 버전을 명시적으로 지정할 수 있다. 작성한 버전에 맞지 않을 경우 npm 혹은 node가 버전이 맞지 않다는 문구와 함께 실행되지 않는다.
참고
Node.js 버전 강제하기
npmrc 파일과 npm config 커맨드
Chat GPT
지난 글에서 node.js 버전 업그레이드 오류를 해결했으나, 이번에는 npm i가 작동하지 않는 에러가 발생했다.. 이 오류 해결하는데 한시간 반은 걸린 것 같은데.. 아무리 서칭해서 적용해도 해결되지 않아서… ㅎ흙흑 겨우 해결방법 글을 발견하여 에러를 해결했다!! 미래의 내가 같은 에러를 마주치면 그때 쉽게 해결할 수 있도록 글을 적어본다..
문제의 에러 화면
어떤 에러인지 확인해보자면 해당 파일에 권한이 없음! 과 파일 이미 존재하니까 삭제하고 다시 해보셈! 그리고 --force 사용해보셈! 인걸로 나는 이해했다.
그래서 --force를 붙여서 해봤다. (대부분 이렇게 하면 해결된다고 하더라) 응, 근데 난 해결이 안됐다 ^^! 그래서 파일도 삭제해봤지만.. 해결이 안됐다.
그러던 중 발견한 정말 나의 구원글..ㅜㅜㅜ 정말 친절히 작성해주셔서 덕분에 해결할 수 있었다.
(자고 싶었는데 해결 안하면 도저히 잠이 안 올 것 같아서 해결방법을 찾던 나에게 자도 된다고 선언해준 글..)
permission denied 에러 해결
원인
해당 에러가 발생한 이유는 이거였다. “접속중인 local 계정이 npm 설치 경로에 권한을 가지고 있지 않다.”
아마 추측하기로는 다른 에러 해결한다고 sudo를 좀 많이(?)사용한 것 같은데 그래서 이 에러가 발생한 것 같다. (해당 글에서도 node를 sudo를 사용하여 설치해서 에러가 발생할 가능성이 높다고 했다.)
해결방법
해당 에러를 해결하는 방법으로 택한 것은 “npm install -g 로 설치되는 디렉토리 경로를 현재 계정의 home directory로 변경” 하는 것이다. (참고한 글의 분이 선택한 방법이다!)
-
npm global directory 생성
mkdir ~/.npm-global
-
생성한 디렉토리에 npm config set 설정
npm config set prefix '~/.npm-global'
-
‘.npm-global’ 파일에 library path 설정 추가
nano ~/.profile
해당 명령어를 입력하면 편집기가 켜지는데, 파일에 다음과 같은 코드를 추가한다.
export PATH=~/.npm-global/bin:$PATH
-
‘.npm-global’ 파일 설정 적용
source ~/.profile
위 단계를 모두 한 후, npm 명령어를 실행했는데도 에러가 계속 발생한다면?
이 모든 명령어들을 수행 한 후, npm i를 실행했더니…..!!!! 설치가 됐다 흠엄ㄴ럼ㅇ러구ㅜㅜ
참고로 나의 경우에는 default directory 권한을 변경하는 것까지 수행한 후에 에러가 해결 됐다..
마치며
정말… 험난했다.. 하.. 그래도 해결하니 기분 좋게 잘 수 있겠더라!ㅎㅎ 이런 맛에 코딩하는 거지… 항상 느끼는 거지만 코딩은 수학문제 같달까… 이 정답을 맞췄을 때의 쾌감.. 내가 이래서 수학을 좋아했지.. 이래서 코딩이 좋은가 보다..헿
참고
[2019.09.01] 오늘의 TIL - npm install 중, permission denied 에러 해결방법
본격 미션 시작하기에 앞서 기본 셋팅을 하던 중… 발생한 에러를 적고자 한다..
나의 브랜치에 fork랑 clone은 매우 간단하게 했고, Node.js와 NPM 버전을 업그레이드 하는 것이.. 시작전부터 날 힘들게 만들었다…
Node.js 버전 업그레이드는 매우 간단하게 성공했다.
n (npm n)을 사용해서 Node.js 버전을 업그레이드 했었는데, 맨 처음에 Node.js를 설치했을 때 NVM으로 했어서 installed와 active 경로가 일치하지 않아 일치시키는 것까지 완료하여 매우 간단하게 해결했다. (미래의 내가 블로그에 글 작성해둔거.. 정말 잘했다 ㅜ)
근데? npm은 자동으로 업그레이드 되지 않았다. 그래서 npm install -g npm 명령어를 통해 업그레이드를 진행하려 했다. 그러나 아무리 터미널에 버전을 확인해도 업그레이드가 되지 않고 이전 버전이라고 나왔다.. 아무리 해도… 그리고 삭제 하고 다시 설치하려고 해도.. 에러 뜨고… 그야말로 1시간의 멘붕시간이었다.
아래 사진 에러 말고도 굉장히 다양한 에러가 나타났다
그러다가 문득 떠오른 것이 Node.js의 installed(npm n)와 active(nvm)의 경로가 다른데.. 그냥 Node.js의 버전 업그레이드를 NVM으로 해보자!였다.
기존에는 n으로 설치하니까 자꾸 두 경로가 다르게 뜬다는 생각이 들었다. Node.js를 NVM으로 설치하면 installed 경로도 active처럼 NVM으로 될 것이라고 생각했다.
그리고 이 생각은 맞았다.
NVM으로 Node.js를 설치하니 모든게 간.단.하게 해결되었다… Node.js 업그레이드와 NPM 업그레이드까지…
그렇다면 왜 NVM으로 Node.js를 설치했을때 NPM도 업그레이드 된 걸까?
N과 NVM
N
n은 npm의 패키지로, npm을 이용해 n을 설치하고 n으로 Node.js 버전을 업그레이드한다. 여기서 주의할 점은 n으로 버전을 업그레이드하고 싶다면 일단 Node.js가 설치되어있어야 한다.
n으로 Node.js 업그레이드를 하는 방법은 해당 링크를 참고하자.
NVM
NVM은 n과 달리 npm의 패키지가 아니라 개별적인 존재이다.
그렇기에 NVM은 Node.js에 의존적이지 않다. 오히려 Node.js가 NVM의 의존적이다. (NVM이 Node Version Manager인 이유랄까…?)
그리고 이번 에러를 통해 느낀 n과 달리 NVM의 가장 큰 장점은. NVM으로 Node.js를 업그레이드하면 NPM의 버전또한 같이 업그레이드가 된다는 것이다! (따로 업그레이드 안해도 되니까 너무 좋더라..)
NVM 사용 방법
N과 NVM 둘 중 무엇을 사용?
이번에 느낀 건데, 둘 중에 뭘 사용하는 것이 좋냐?라고 묻는다면 난 NVM을 하겠다.. 일단 Node.js에 의존적이지 않아서 좋은 것 같다. 그리고 NPM도 같이 업그레이드가 되고…
이번에 느낀건 사람들이 많이 쓰는데는 이유가 있다~^^ 라는 것이다.
마치며
미래의 나.. Node.js 업그레이드… N아니고 NVM으로 했다.. 자꾸 N으로 업그레이드 하지 말아라… 에러 또 날라..ㅜ
+추가
해당 에러는 잡았지만 npm i가 안되는 에러 해결 안됨… (추후에 계속)
참고
Node.js 버전 변경하기 (with NVM 사용법)
node.js 버전 관리 매니저::nvm과 n 비교 및 nvm 설치 방법 정리
이번주 월요일, 밤을 새우며 자소서를 작성해서 우아한테크코스 6기 모집에 신청했다. (모집하는 것을 늦게 알아서 오전 10시까지 자소서 작성하느라 힘들었다..)
우아한테크코스는 6기 선발을 하기 전에 프리코스를 진행하는데, 4주동안 주어진 미션을 수행하는 것이다.
우테코에 선발되면 너무너무 좋겠지만.. 선발되지 않더라도 프리코스 참여로 배우는 점이 굉장히 많을 것 같아서 망설임 없이 신청했다.
글을 작성하는 현재 날짜로 오후 3시에 메일로 1주차 미션 내용이 도착했다. 기본 설정과 미션내용이 주어졌는데, 미션을 본격적으로 시작하기 전에 커밋 메세지를 제대로 작성해야 할 것 같다는 생각이 들었다. 기존에는 나만 확인하기 때문에 대충 작성했…다..ㅎ.. 프로젝트의 경우에는 간단하게 적었고.. 팀원이 이해하지 못하면 말로 설명해주면 되니까! 라는 마음으로 ^^.. 열심히 작성하지 않았었다.
하지만 프리코스의 경우에는 내가 설명을 해줄 수도 없는 상황이니까…! 이 기회를 삼아 정석대로 커밋 메세지를 작성해보고자 글을 작성한다.
커밋 메세지를 잘 작성해야 하는 이유
일단 우리는 왜 커밋 메세지를 잘 작성해야 할까?
그 이유는 프로젝트는 대부분 팀단위로 이뤄지기 때문이다. 만약 개인 프로젝트라면 솔직히 내가 알아볼 정도로만 작성하면 된다고 생각한다. (남이 볼거 아니니까?)
하지만 대부분의 프로젝트는 개인이 아닌 팀단위로 이뤄지고, 팀원마다 맡은 역할이 다르다. 결국 각자 개발한 코드를 합쳐야 하는데, 이때 분명 다른 팀원의 코드를 확인하게 되는 일이 진짜 무조건 최소 1번은 발생한다. (UNIVE.US나 DrawMap을 진행했을 때도 셀 수 없이 다른 팀원 코드를 확인했다.) 다른 사람의 코드로 인해 내 코드가 충돌 날 수 도 있고, 다른 팀원이 개발한 기능을 가져다 사용하는 일이 많기 때문이다.
그렇기에 다른 팀원이 개발 혹은 수정한 내용을 쉽게 확인하기 위해서 히스토리 (커밋한 내용)를 확인하게 된다. 이때, 어떤 기능을 개발했는지 수정했는지 커밋 메세지만을 보고 명확히 알 수 있다면? 보고자 하는 내용을 정말 간단하게 찾을 수 있을 것이다.
그렇다 위의 내용은 내 경험담이다 ^^. 다른 글을 참고하지 않고 순수 나의 경험담을 작성한 것이다.. 그렇기에 이번에 두 프로젝트를 동시에 진행하면서 느낀 것은… 커밋 메세지… 잘.. 명확히.. 작성하자… 그리고 커밋… 한번에 하지 말고… 기능마다 커밋하자… 정말 뼈저리기 느낀 사실이다.
좋은 커밋 메세지
그렇다면 좋은 커밋 메세지란 무엇일까?
해당 로그에서 어떤 것을 수행했는지 (기능 추가, 수정 등), 기능을 추가했다면 어떤 기능을 추가했는지와 같은 내용 등
해당 메세지를 통해서 어떤 것을 수행했는지 명확히 알 수 있어야 한다.
개발에 개도 모르는 사람이 봐도 음~ 이런 걸 수행했군!을 메세지만 보고 알 수 있어야 한다고 나는 생각한다!
좋은 커밋 메세지 작성 방법
프로젝트마다 커밋하는 방법을 따로 규칙으로 정했을 수도 있다. 지금부터 내가 설명하는 것은 ‘대체적으로’ 많이 사용하는 커밋 메세지 작성 방법이다.
커밋 메세지 구조
type(타입): title(제목)
# 예시
# feat: 음료 선택하기 기능 구현
위와 같이 작성하면 된다. 저 부분을 header라고 하는데, body나 footer도 존재하지만 대부분 사용 안하는 것 같다. 그래서 위에 header 부분만 작성하면 될 것 같다.
Type 키워드
- feat: 새로운 기능 추가
- fix: 버그 수정
- docs: 문서 수정
- style: 코드 스타일 변경 (코드 포매팅, 세미콜론 누락 등) 기능 수정이 없는 경우
- design: 사용자 UI 디자인 변경 (CSS 등)
- test: 테스트 코드, 리팩토링 테스트 코드 추가
- refactor: 코드 리팩토링
- build: 빌드 파일 수정
- ci: CI 설정 파일 수정
- perf: 성능 개선
- chore: 이 외에 자잘한 수정
- rename: 파일 혹은 폴더명을 수정만 한 경우
- remove: 파일을 삭제만 한 경우
대부분이 해당 타입 키워드를 사용한다.
추가로, 우테코에서 어떻게 커밋 메세지를 작성하나 확인해봤는데 위와 같이 type: title 형식으로 하더라! 앞으로는 위에 처럼 좋은 커밋 메세지를 작성해보겠다..!
참고
Git 커밋 메시지 규칙
[Git] 좋은 commit message 작성법