1218 강의 - 요약필요

JVM이 ArithmaticException이라는 객체를 만들어서 Excoption을 발생 시킨다.

 

차라리 에러가 나서 프로그램이 죽는 것이 더 나은 경우가 있다.

(프로그램이 죽지 않고 잘못된 값을 리턴하는게 더 치명적이다.)

 

Try-catch를 사용해서 에러가 생겨도 프로그램이 종료되지 않게 만들 수 있다.

하지만 항상 그것이 옳은 것은 아니다.

 

모든 Exception을 처리하는게 아니다.

발생 가능한 Exception을 알려주고 해당 Exception을 처리하도록 할 수 있다.

 

Cal.divede()에서 발생 한 exception을 참조하는 변수 ae

 

UI를 사용하는쪽에서 에러 메시지가 출력되게 해야한다.

è 오류가 발생한 쪽(사용자)에 메시지가 출력이 되어야한다.

 

RuntimeException의 자손이 발생 했을때는 굳이 throws를 적어 줄 필요는 없다.

-          적어주지 않아도 알아서 처리해준다.

-          그래도 적어주는 것이 명시적으로 알기 쉽기 때문에 좋다.

 

조상중에 RuntimeException이 없다면 checked Exception이라 한다.

Checked Exception의 경우는 try-catch로 처리를 해주지 않으면 compile 에러를 발생시킨다.

-          반드시

o   Try-catch

o   Throws

-          Main 메소드에 throws를 줘버리면 JVM에 Exception 핸들링을 맡기게 된다.

o   JVM이 죽어버린다. -> 프로그램 종료 -> 이유를 알 수가 없다.

되도록이면 Runtime Exception을 발생하도록 한다.

-          Checked Exception이 발생하면 코드가 어지러워진다.

-          사용자에게 강제하지 않는 것이 좋다.

 

객체지향에서 중요한 것

-          프로그램을 만든다는 것은 설계가 중요하다.

-          설계 – 내가 만들 클래스 이름을 정하는 것이다

o   클래스는 메소드를 가지고 그 메소드 이름을 정하는 것이다.

o   이름 -> 직관성(이름만 봐도 알아야 한다)

-          Exception 역시 마찬가지

o   굳이 My Exception과 같은 클래스를 만드는 것은 어떠한 Exception이 발생 했을 때 사용자에게 알리기 위함이다.

Layer

-          UI만 처리하는 레이어

-          계산만 처리하는 레이어……

 

 

각각의 코드는 각각의 Exception 발생

-          각각의 Exception을 공통의 Exception으로 발생하게 만든다.

-          각각의 Exception을 다 처리 할 필요 없이 MyException만 처리해주면 된다.

-          UI에서 무슨 Exception이 발생했는지 알게하고 싶다면 각각의 Exception을 전부 처리해주면 된다.

UI사용자에게는 오류가 발생했을 때 디테일 한 오류를 알 필요는 없다.

어디에서 발생했다 정도로 살짝만 보여주면 된다.

대신 하위에서는 오류의 디테일한 로그를 남겨야한다.

 

 

 

 

콘솔에서 실행하는 프로그램

-          터미널

UI -à DAO라는 클래스를 사용한다.

-          DAO는 파일에 읽고 쓰는 기능

-          DAO는 메모리에 자료구조를 가질 수 있다.

키보드로부터 명함정보를 입력 받는다.

메뉴를 선택한다.

결과를 출력한다.

 

프로그램이 완벽하다는 것을 증명할 방법은 없다.

테스트한 것 까지는 완벽하다고 할 수 있다.

 

1.       Dao 클래스명 정하기

2.       Dao가 어떻게 동작할지를 정한다

3.       Dao가 어떤 메소드를 가질지 정한다. (메소드명, 파라미터, 리턴타입)

4.       각자 Dao를 만들고 테스트코드를 작성

a.       조원끼리 이야기를 한다.

 

검증을 할 코드가 필요하다

눈으로 확인하는 것이 아니다

무조건 실패하는 테스트메소드를 만들고 해당 메소드를 구현하여 테스트를 통과하게 한다

테스트 주도 개발

Test Driven Development

왜? -> 테스트를 하기 위해선 기능정의를 거쳐야 한다. -> 기능을 먼저 정의하고 구현하라고 강제한다.