qwef

먼저, 우리가 바꿔 줄 커스텀 예외를 만든다. public class MyDbException extends RuntimeException{ public MyDbException() { } public MyDbException(String message) { super(message); } public MyDbException(String message, Throwable cause) { super(message, cause); } public MyDbException(Throwable cause) { super(cause); } } 생성자는 그냥 빈거, 메시지 넣을 수 있는 거, 그리고 바꿔서 던지기 전의 예외가 어디서 부터 온 예외인지 같이 첨부해서 던지기 위해서는 Throwable이 반드시 필요하다..

먼저 체크예외로 해결하려는 시도를 한다.. 안 좋긴 하지만 시키려는 모양이다. 우리가 먼저, @Transactional public void accountTransfer(String fromId, String toId, int money) throws SQLException { Member fromMember = memberRepository.findById(fromId); Member toMember = memberRepository.findById(toId); memberRepository.update(fromId, fromMember.getMoney() - money); validation(toMember); memberRepository.update(toId, toMember.getMoney() ..

Hello!!! {{ isActive }} isActive가 true면 active라는 단어를 넣는거고 false면 active라는 단어를 없에는 거다. { active : isActive} 일종의 조건문 같은 개념이다. isActive 대신 조건문을 쓰면 된다.

데이터가 필수적으로 변경이 필요할 경우 watch 콜백보단 computed 쓰는 게 나음. watch로 내가 콜백함수와 함께 변경을 감지할 데이터를 지정하면, 그 데이터가 변경되었을 때 콜백함수를 실행 computed는 사용하는 데이터가 변경될 시. watch : { msg(){ console.log(this.msg); } } 왓치는 걍 이렇게 쓰면 됨. this.msg를 감시하게 됨. 함수명과 같은 변수를 감시하는 거임. 근데 참고로, watch가 변화를 감지하는 것 이므로, 만약 watch로 저 데이터를 바꾸게 되면 무한 재귀가 일어남. Maximum recursive 이러는 거 보니까 내부적으로 재귀를 사용하는 듯. watch가 직접 감시하는 데이터를 바꾸게 하면 안됨. 또 watch끼리도 서로 그..

const printHello = ()=>{ console.log('Hello'); } let nums = [1,2,3,4]; const PI = 3.14; class User{ name; constructor(name){ this.name = name; } introduce(){ console.log(`Hello, my name is ${this.name}`); } } let user1 = new User('user1'); function hello(msg){ console.log('export function' + msg); } exports.printHello = printHello; exports.nums = nums; exports.PI = PI; exports.User = User; expor..

예외 전환 시 꼭 기존 예외 포함해야 함. 어떤 예외에서 파생되어 왔는 지 알아야 예외의 이유를 아니까. 예외 log.info() 할 때 e 넣으면 스택 트레이스 확인할 수 있음. log.info("ex", e) 저 메시지랑 그 뒤에 스택 트레이스 찍히기 시작. 예외는 로그 찍을 때 {} 문자열에 이렇게 바인딩 할 곳 넣어주지 않아도 알아서 잘 나옴. @Test void printEx(){ Controller controller = new Controller(); try { controller.request(); }catch(Exception e){ log.info("ex",e); } } static class Repository { public void call() { try { runSQL(); } ..

이제 언체크 예외를 쓸 것이다. 언체크 예외를 쓰면 이제 명시적으로 예외를 던져 줄 필요가 없다. 그럼 이제 코드도 깔끔해지고 더 이상 SQLException 같은 특정기술의 예외에 의존을 하지 않아도 된다. public class UnCheckedAppTest { @Test public void unChecked(){ Controller controller = new Controller(); assertThatThrownBy(()-> controller.request()) .isInstanceOf(Exception.class); } static class Controller{ Service service = new Service(); public void request(){ service.logic()..

그냥 단어 두개 이어진 거 - 행동 -- 어디 소속 __ header__menu clean--float send-btn--hover https://nykim.work/15 [CSS 방법론] BEM 방식 오늘은 CSS 방법론을 다뤄보겠습니다 ;-) 말이 거창하긴 한데 쉽게 풀어쓰면 'CSS 클래스네임을 어떻게 지으면 좋을지' 고민해보는 거죠. 방법론에는 여러 가지가 있는데, 최근 BEM을 실무에 도입하 nykim.work BEM 방식이라고 함.

일단 기본적으로 언체크 예외를 사용을 한다. 체크예외는 비즈니스 로직상 의도적으로 던지는 경우에만 주로 사용한다. 계좌이체 실패, 결제 시 포인트 부족, 로그인 id, pw 불일치 등 조금 뭐랄까 의도적으로 처리할 일이 있는? 이런 경우는 고객에게 알리거나 등. 물론 위의 경우도 100% 체크 예외로 만들어야 하는 것은 아님. 근데, 예를 들어 계좌 이체처럼 매우 심각한 문제는 이런 개발자가 놓치면 안되는 예외는 체크 예외로 해 두면 컴파일러가 인지할 수 있음. 체크 예외는 뭔가 개발자가 의도적으로 인지하고 싶을 때, 처리하고 싶을 때 컴파일러가 잡아주므로 보통은 런타임예외(언체크예외)를 주로 씀. 저렇게 의도적으로 인지하거나 처리하고 싶을 경우를 제외 하고는. 아, 이거는 에러 나면 ~~ 이렇게 처리하..

체크예외 : 예외를 잡아서 처리하지 않으면 항상 throws 해서 위에 던져야 한다. 언체크 예외 : 예외를 잡아서 처리하지 않아도 throws를 생략할 수 있다. 알아서 던져진다. @Slf4j public class UncheckedTest { Service service = new Service(); @Test public void unchecked_catch(){ service.callCatch(); } @Test public void unchecked_throw(){ assertThatThrownBy(()->service.callThrow()).isInstanceOf(MyUncheckedException.class); } static class MyUncheckedException extends ..