2022-02-04(금) 12주차 2일

com.eomcs.app1.App.java

divide 기능 추가

0으로 나누는 거에 대해 에러 처리 안 함

JVM의 예외 처리

07-예외처리 / 1 페이지

JVM --- 호출 ---> App main()

🔹 시퀀스 다이어그램 (Sequence Diagram)
시간의 흐름에 따른 객체와 객체 간의 상호 작용을 표현할 수 있다.

🔹 Graph : relation과 interaction이 표현된 다이어그램
데이터와 데이터 사이의 관계
데이터와 데이터 사이의 상호 작용을 표현한 거

Object-Graph Navigation Language (OGNL)
상호 관계와 상호 작용을 표현하는 언어
Object 객체 간의 상호 작용
Graph ← 여기서도 graph
Navigation
Language

값과 값 사이에 관계가 있고 서로 상호 작용 하는 게 있다면 그게 바로 graph

프로그래밍 세계에서 graph는 값과 값 사이의 관계, 값과 값 사이의 상호 작용을 표현하는 게 graph

시퀀스 다이어그램은 객체와 객체 사이의 관계를 시간의 흐름에 따라 표현해서 흐름을 이해하기 좋다

클래스 객체

이 객체의 생성에서 소멸까지 보여주는 생명선(Life Line)

JVM 실행 → App main() 호출 → App → prompt() 호출 → Console → CommandHandler
App ---호출---> CommandHandler.doDivide()
→ 나누기 연산 수행
만약 0으로 나눌 경우 예외 발생
if (0으로 나눌 경우) {예외 발생};
호출자에게 예외를 보고한다. 넘긴다.
호출자에게 예외 상황 전달
예외 상황에 대해서 어떻게 하겠다고 안 적으면 호출자에게 전달함
만약 예외에 대한 처리가 없다면
if (예외에 대한 처리가 없다면) {호출자에게 전달};
JVM이 main() 호출했으니까 JVM에 예외 상황 전달
JVM은 예외 상황을 전달 받으면 예외 상황에 대한 정보를 출력한 후 실행을 종료한다. 이게 바로 JVM이 하는 일.

예외가 발생하더라도 JVM을 멈추지 않는 방법

✓ 예외가 발생한 곳에서 예외를 처리하라!
✓ JVM까지 예외 상황이 전달되게 하지 말라!

나누기 연산 수행 중 에러 발생하면 거기서 예외 처리
어느 지점에서 예외가 발생할지 예측
규칙이 따로 없음
예외를 처리하는 문법은 존재하는데

예외 처리 문법
try ~ catch ~ finally 문법을 사용해서 처리

if (0으로 나눌 경우) {예외 발생}; ⇒ 예외 처리 ⇒ try ~ catch ~ finally 문법을 사용해서 처리

예외가 발생할만한 코드를 try 블록 안에 가둔다.

Exception : 예외 정보를 받는 타입

try 블록에서 발생된 예외를 잡는 블록을 준비한다.

예외에 대한 적절한 조치를 취하는 코드를 이 블록에 둔다.

프로그램을 실행하는 중 예외가 발생하더라도 시스템을 멈추지 않고 계속 실행하게 만들어주는 문법

예외가 발생하더라도 멈추지 않고 계속 실행하게 도와주는 문법

try에 가두는 범위를

예외가 발생했을 때

숫자 받는 부분도 try 안에 넣는다

      try {
        // 예외가 발생할만한 코드를 try 블록 안에 가둔다.
        int v1 = command.getInt(0);
        int v2 = command.getInt(1);
        System.out.printf("%d / %d = %d\n", v1, v2, (v1 / v2));
      } catch (Exception e) { // try 블록에서 발생된 예외를 잡는 블록을 준비한다.
        // 예외에 대한 적절한 조치를 취하는 코드를 이 블록에 둔다.
        System.out.println("나누기 연산 중 오류 발생!");
      }

그물을 뒤로 더 땡기자

예외가 발생하더라도 JVM을 멈추지 않게 하는 방법 - 예외 처리2

예외가 발생한 지점에서 캐치하지 말고 그물을 뒤쪽에 친다

App ← 여기서 예외를 잡는다
이점?
나누기 연산 뿐만 아니라 다른 연산에서 발생한 예외도 잡을 수 있다.

예외 처리 문법의 존재 이유

예외 상황이 발생하더라도 시스템을 멈추지 않게 설정하는 문법
적절한 조치를 취할 수 있는 방법을 제공한다.

미니 프로젝트(project-app1) 8.1단계: 예외 처리 문법 적용

com.eomcs.exception.ex1

예외 처리 문법이 등장하기 전에는 return 값을 통해서 예외 상황을 알렸다.
예외가 발생하면 시스템을 멈춘다.
문제점 시스템이 멈추는 문제점 때문에 예외 처리 문법이 등장하게 되었다.

com.eomcs.exception.ex2

RuntimeException ← 실행 중에 발생된 예외를 던질 때

throw new RuntimeException("해당 연산자를 지원하지 않습니다.");

상자 안에 담아서 던진다

예외 정보를 담을 때도 아무 상자에 담지 말고 적절한 상자에 담아서 던진다

throw : 예외를 던지는 문법

던진 예외는 try - catch로 받아라

try : 예외를 받는 문법

예외를 던질 수도 있는 메서드를 호출할 때는 try 블록 안에서 호출한다.

InputMismatchException

메뉴판이 API 문서
도구 사용법이 들어 있는 문서
도구들에 관련된 문서
API 문서

com.eomcs.exception.ex3

예외 상황 알리기 - throw 명령

Object
   - Throwable
      - Error ← JVM 오류, 개발자가 던지면 안 된다
      - Exception ← App 오류

Throwable 또는 그 자식 객체를 던지라는 거

에러 객체는 2가지로 나뉜다

개발자가 터치할 오류가 아님
개발자가 던지면 안 된다

throw new String("예외가 발생했습니다!"); // 컴파일 오류!
No exception of type String can be thrown; an exception type must be a subclass of Throwable

getMessage() : 생성자에 넘겨준 값을 그대로 리턴한다.
throw new RuntimeException("예외가 발생했습니다!");

즉시 현재 메서드의 실행을 멈추고 호출자에게 예외 처리를 위임한다.

java.lang.Error (시스템 오류)
개발자가 사용하는 클래스가 아니다.

현재 애플리케이션 상태를 백업

https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Throwable.html

Exception 계열의 예외를 던질 경우,
반드시 메서드 선언부에 어떤 예외를 던지는지 지정해야 한다.

오류를 던진다면 반드시 메서드 선언부에 어떤 오류를 던지는지 선언해야 한다.

메서드의 throws에 선언할 수 있는 클래스는 Throwable 타입만 가능한다.
보통 클래스 이름은 명사나 명사구 형태인데 형용사임

throw로 던질 수 있는 객체는 오직 java.lang.Throwable 타입만 가능하다.

Throwable 클래스를 직접 사용하지 말고 그 하위 클래스를 사용하라

여러 개의 오류를 던지는 경우 메서드 선언부에 그대로 나열하라.
그래서 throws
순서는 상관 없음

Exception의 서브 클래스임에도 불구하고
RuntimeException 객체를 던질 경우,
메서드 선언부에 예외를 던진다고 표시하지 않아도 된다.

스텔스 모드 지원..?
프로그래밍 편의성 때문에 등장한 클래스

공통 분모를 사용하여 퉁치는 방법
그러나 호출자에게 어떤 오류가 발생하는지 정확하게 알려주는 것이 유지보수에 도움이 된다.

예외를 던지는 메서드를 호출할 때는 try - catch
예외를 던진다고 했으면 그 예외를 어떻게 할 지

main() 선언부에서 선언하는 건 지양하기

컴파일러가 통과시켜준다

com.eomcs.exception.ex3.Exam0430.java

OR 연산자를 사용하여 여러 개의 예외를 묶어 받을 수 있다.

정상적으로 실행하든, 아니면 예외가 발생하여 catch 블록을 실행하든
finally 블록은 무조건 실행한다.

try 에서 사용한 자원을 해제시키는 코드를 주로 둔다.

JVM이 종료되면 OS는 JVM이 사용한 모든 자원을 자동으로 회수하기 때문에

그러나 365일 24시간 내내 실행되는 시스템이라면,

짧으면 몇 주 길면 몇 달
JVM이 종료돼야지

항상 자원을 사용한 후 해제시키는 것을 습관적으로 해야 한다.

변수를 왜 try문 밖에 뒀습니까?
블록 안에 선언된 변수는 사용할 수 없다
그래서 바깥에 둔 거

try-with-resources

단 java.lang.AutoCloseable 구현체에 대해서만 가능하다!

반드시 AutoCloseable 구현체이어야 한다.

com.eomcs.exception.ex5

https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/NumberFormatException.html

RuntimeException 자손이라서 안 적어도 됐던 거

마찬가지

둘 다 RuntimeException의 자손이므로
RuntimeException으로 퉁쳐서 받는다

에러 메시지 없으면 getMessage()로 꺼내면 null 나옴

메서드 호출 스택을 거꾸로 따라 올라가면서 출력한다

아 이거 게시글 관련 예외구나 바로 알 수 있음

com.eomcs.exception.ex5.BoardException.java

기능 추가도 안 했는데 왜 상속 받았나

com.eomcs.net.ex03

Scanner 데코레이터는 아님
하는 일은 데코레이터 같지만

e.printStackTrace();
메서드를 누가 호출했는지 거꾸로 쭉 따라 올라가면서 출력
예외가 발생했는데 어느 부분에서 예외가 발생했는지 추적할 때 사용

소켓을 만드는데 이미 그 포트 번호를 사용 중일 때 예외 발생

close()도 예외가 발생함

close() 예외 처리

보통 출력 스트림을 닫음
출력 스트림 닫기 전에 flush()
버퍼를 쓸 때 버퍼가 차지 않으면 출력을 안 함
close() 안에서 flush() 호출

입력 출력 따로 닫아야 됨

110번과 111번의 차이
110번은 개발자가 직접 작성
111번은 개발자가 따로 finally를 통해서 close() 할 필요 없다는 거

가능하면 try with resource 쓰기

통상적으로는 클라이언트가 먼저 보냄

write()와 read() 그리고 랜카드 메모리

랜카드 = NIC (Network Interface Card)

랜카드에 메모리가 있는데
메모리가 어떤 용도로 쓰이냐

🔹 랜카드 메모리
­- 보내는 데이터를 임시 보관
­- 받은 데이터를 App.이 가져갈 때까지 임시 보관
하는 용도 쓰인다

write()를 호출하면 메모리로 출력?
메모리에 임시 저장됨
메모리에 임시 저장된 걸 read()를 호출하면 메모리에 저장된 걸 가져온다
write 하는 순간
랜카드 칩..

write()는 기다리지 않음
read()는 기다림. 메모리에 데이터가 없으면 블로킹이 걸린다
메모리에 데이터가 들어올 때까지 계속 기다림
write()는 저쪽에서 읽을 때까지 안 기다림
write()는 메모리에 저장하는 게 끝. 클라이언트 안 기다림.

🔹 write()
­- 메모리로 출력
­- 전송 완료를 기다리지 않는다
­- 출력은 블로킹이 없다

🔹 read()
­- 메모리에서 읽는다
­- 수신이 완료될 때까지 기다려야 한다
­- 원하는 양의 데이터를 읽을 때까지 블로킹한다.

상대편이 읽을 때까지 내가 출력을 기다리는 게 아니라
write는 그냥 그대로 출력하기 때문에 상대편이 읽든 말든 안 따짐

그래픽 카드와 메모리

CPU ----- RAM 연결되어 있음

그래픽 카드에는 GPU가 있고
좌표 부동소수점
일반 CPU는 부동소수점만 계산하는 용도로 만든 게 아니라 다용도로 쓸 수 있
GPU는 그래픽 처리 위해 부동소수점 계산에 특화해서 만든 거
블록체인 알고리즘 많이 쓰임
블록체인은 CPU가 아니라 GPU를 쓰면 더 빠른 속도로