2023-02-08-TIL
2023-02-08-TIL
Today I Learned
Checked Exception vs Unchecked Exception
자바 예외는 컴파일러가 처리를 강제하는지에 따라 둘로 나뉜다. checked exception은 Exception을 상속하지만 RuntimeException 계열은 아닌 예외로, 메서드 안에서 catch로 잡거나 throws로 선언해야 컴파일된다. unchecked exception은 RuntimeException, Error와 그 하위 클래스이고, 이 “잡거나 선언하라(catch or specify)”는 요구에서 빠진다.
Oracle Java Tutorial은 메서드가 던질 수 있는 checked exception을 파라미터, 반환값과 같은 공개 인터페이스의 일부로 본다. 반면 0으로 나누기, null 참조 접근, 잘못된 인덱스 같은 런타임 예외는 프로그래밍 오류에서 생기므로 호출자가 복구하리라 기대하기 어렵고, 그래서 선언을 강제하지 않는다. 튜토리얼이 내리는 기준은 간단하다. 호출자가 복구할 수 있으면 checked, 할 수 없으면 unchecked로 만든다. 예외 선언이 귀찮다는 이유만으로 RuntimeException을 상속하지 말라는 경고도 같이 붙어 있다.
스프링을 쓸 때는 한 가지를 더 기억해야 한다. @Transactional은 기본적으로 RuntimeException과 Error에서만 롤백하고, checked exception이 던져지면 롤백하지 않는다. checked exception에서도 롤백하려면 rollbackFor 같은 롤백 규칙을 지정해야 한다.
- https://rollbar.com/blog/how-to-handle-checked-unchecked-exceptions-in-java/
- https://stackify.com/specify-handle-exceptions-java/
- https://stackify.com/common-mistakes-handling-java-exception/
- https://www.geeksforgeeks.org/checked-vs-unchecked-exceptions-in-java/
- https://www.tutorialspoint.com/how-can-we-decide-that-custom-exception-should-be-checked-or-unchecked-in-java
- https://howtodoinjava.com/java/exception-handling/checked-vs-unchecked-exceptions-in-java/
- https://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html
- https://devlog-wjdrbs96.tistory.com/351
Custom Exception vs Runtime Exception
사용자 정의 예외를 만들지, IllegalArgumentException, IllegalStateException 같은 표준 예외를 그대로 쓸지에 대한 논쟁이다. Tecoble 글은 양쪽 주장을 정리한다. 표준 예외 쪽은 메시지만으로도 의미가 전달되고, 익숙한 예외가 더 읽기 쉬우며, 예외 클래스가 지나치게 늘어나면 관리 비용이 생긴다고 본다. 사용자 정의 예외 쪽은 PostNotFoundException처럼 이름만으로 상황을 알 수 있고, 생성자에서 크기나 인덱스 같은 상세 정보를 일관되게 담을 수 있으며, 같은 예외가 여러 곳에서 던져질 때 관련 정보를 한 클래스에 모을 수 있다는 점을 든다.
.NET 문서의 예외 모범 사례도 비슷한 기준을 둔다. 미리 정의된 예외가 맞지 않을 때만 새 예외 클래스를 도입하라는 것이다. 스프링 애플리케이션에서는 사용자 정의 예외를 보통 RuntimeException 하위로 만들고, 에러 코드를 필드로 넣어 전역 핸들러에서 한 번에 응답으로 바꾸는 경우가 많다.
- https://stackoverflow.com/questions/52437023/best-way-to-add-the-custom-exception-for-the-spring-boot-code
- https://tecoble.techcourse.co.kr/post/2020-08-17-custom-exception/
- https://stackoverflow.com/questions/19857008/extending-exception-runtimeexception-in-java
- https://stackify.com/java-custom-exceptions/
- https://www.java67.com/2012/12/difference-between-runtimeexception-and-checked-exception.html
- https://www.baeldung.com/java-new-custom-exception
- https://m.blog.naver.com/sthwin/221144722072
- https://learn.microsoft.com/en-us/dotnet/standard/exceptions/best-practices-for-exceptions
- https://www.scaler.com/topics/custom-exception-in-java/
- https://www.youtube.com/watch?v=fVXC11OwbHs
- https://medium.com/nerd-for-tech/custom-exceptions-in-java-41cea0021aee
Exception vs Runtime Exception
Exception을 직접 상속하면 checked, RuntimeException을 상속하면 unchecked가 된다. 사용자 정의 예외를 어느 쪽 아래에 둘지는 위의 기준, 즉 호출자가 복구할 수 있는지로 정한다.
- https://ch4njun.tistory.com/272
Exception Handling in Java
try/catch/finally, throws, 예외 체이닝(cause를 넘겨 원인을 보존하는 것), try-with-resources까지 자바 예외 처리 문법 전반을 정리한 튜토리얼이다.
- https://www.digitalocean.com/community/tutorials/exception-handling-in-java
Exception Handling in Spring
스프링 MVC에서 컨트롤러 밖으로 나간 예외를 HTTP 응답으로 바꾸는 방법은 크게 셋이다. Spring 블로그의 “Exception Handling in Spring MVC” 글이 이를 정리한다. 직접 만든 예외 클래스에 @ResponseStatus를 붙여 상태 코드를 정하거나, 컨트롤러 안에 @ExceptionHandler 메서드를 두어 같은 컨트롤러에서 난 예외를 처리하거나, @ControllerAdvice 클래스에 핸들러를 모아 전역으로 처리한다. 그 아래에는 이 모든 것을 구현하는 HandlerExceptionResolver가 있다. 처리되지 않은 예외는 기본적으로 500 응답이 된다.
Request Parameter in Spring
요청 파라미터가 많을 때 @RequestParam을 여러 개 나열하는 대신 모델 클래스 하나로 받는 방법이다. 스프링 문서에 따르면 @ModelAttribute는 생략할 수 있고, 단순 값 타입이 아니면서 다른 리졸버가 처리하지 않는 파라미터는 기본적으로 모델 속성으로 취급된다. 이때 객체는 생성자 바인딩이나 setter(프로퍼티) 바인딩으로 채워지고, 바인딩 오류가 나면 기본적으로 MethodArgumentNotValidException이 발생한다.
- https://bum752.github.io/posts/Spring-%EC%96%B4%ED%94%8C%EB%A6%AC%EC%BC%80%EC%9D%B4%EC%85%98%EC%97%90%EC%84%9C-Request-Parameter%EB%A5%BC-%EB%AA%A8%EB%8D%B8-%ED%81%B4%EB%9E%98%EC%8A%A4%EB%A1%9C-%EC%B2%98%EB%A6%AC%ED%95%98%EA%B8%B0/
Jib vs Dockerfile
Jib은 Google이 만든 오픈소스 컨테이너 이미지 빌더로, Maven과 Gradle 플러그인 형태로 동작한다. Google Cloud 블로그의 비교 글에 따르면 Jib은 의존성, 리소스, 컴파일된 애플리케이션을 별도 레이어로 나눠서 코드만 바뀌면 마지막 레이어만 다시 올리면 되고, 이미지를 외부 레지스트리에 바로 올린다면 로컬에 Docker가 없어도 빌드할 수 있다. Dockerfile은 어떤 언어든 쓸 수 있고 모든 단계를 직접 통제할 수 있는 대신, 레이어 구성과 캐시 최적화를 스스로 챙겨야 한다. 같은 글은 Buildpacks도 함께 비교하는데, 설정 없이 동작하지만 이미지가 크고 레이어가 최적이 아니라고 평가한다.
Google Cloud의 한국어 Jib 시작 가이드 링크는 지금은 404를 반환한다.
- https://cloud.google.com/blog/topics/developers-practitioners/comparing-containerization-methods-buildpacks-jib-and-dockerfile
- https://www.linkedin.com/pulse/docker-image-build-vs-jib-eran-shaham
- https://tomgregory.com/jib-vs-spring-boot-for-building-docker-images/
- https://nesoy.github.io/articles/2020-11/Jib
- https://gc.hosting.kr/blog-serverless-jib-container/
- https://alden-kang.tistory.com/1
- https://cloud.google.com/java/getting-started/jib?hl=ko
FFmpeg Wrapper Library in Java
자바에서 FFmpeg를 쓰는 가장 흔한 방법은 설치된 ffmpeg 실행 파일을 프로세스로 호출하는 것이다. bramp/ffmpeg-cli-wrapper는 이 방식을 감싼 라이브러리로, ffmpeg와 ffprobe 경로를 지정하고 빌더 API로 명령줄 옵션을 조립한다. 결국 CLI를 실행하는 구조이므로 서버에 FFmpeg 바이너리가 설치되어 있어야 한다. 함께 저장한 jibbex/jib-FFmpeg는 이름과 달리 자바 라이브러리가 아니라 Node.js와 Electron으로 만든 FFmpeg GUI이고, 2022년에 보관(archive) 처리되었다.
- https://github.com/jibbex/jib-FFmpeg
- https://jodu.tistory.com/30
- https://swampwar.github.io/2020/07/02/java%EC%97%90%EC%84%9C-ffmpeg-%EC%82%AC%EC%9A%A9%ED%95%98%EA%B8%B0.html
- https://github.com/bramp/ffmpeg-cli-wrapper
댓글
아직 댓글이 없습니다