try {
예외가 발생할 가능성이 있는 실행문
}catch (Exception 클래스명 e){
예외 처리문
}
try 블록에 실제 실행되어야 하는 코드가 들어가며 Exception이 발생할 가능성이 있는 코드가 들어간다.
catch 블록에는 Exception이 발생하면 실행되는 코드가 들어갑니다. 즉 예외 처리를 하는 코드다.
throw
: 개발자가 의도적으로 예외를 발생시키는 것이다.
throw라는 키워드를 이용하며, 주로 비즈니스 로직을 구현하는 과정 중 컴파일에는 문제가 없지만 해당 비즈니스 로직이 개발자가 의도한 대로 통과하지 못했을 경우 고의로 예외를 발생시켜야 할 때 사용한다.
다음 예시는 숫자가 아닌 경우 혹은 3미만 20 초과인 경우 예외를 발생시키는 경우다.
여기서 min은 3, max는 20을 의미한다.
예외가 발생하면, IllegalArgumentException()으로 처리된다.
IllegalArgumentException()
: 적합하지 않거나(illegal) 적절하지 못한(inappropriate) 인자를 메서드에 넘겨주었을 때 발생합니다.
이처럼 throw
키워드를 사용하면 개발자의 판단에 따라 강제로 예외를 발생시킬 수 있다.
throws
: 메서드 내에서 예외 처리를 하지 않고 해당 메서드를 사용한 곳에서 예외 처리를 하도록 예외를 다른 곳으로 던지는 것이다.
즉, 예외를 전가시키는 것이다.
public class Test {
public static void main(String[] args) {
int a = 2;
int b = 0;
try {
divide(a,b);
} catch (ArithmeticException e) {
e.printStackTrace();
}
}
public static int divide(int a, int b) throws ArithmeticException {
if (b == 0) {
throw new ArithmeticException("0으로 나눌 수 없습니다.");
}
return a / b;
}
}
여기서 divide 메서드는 예외를 자신이 처리하지 않고 throws 키워드를 통해 자신을 호출한 main 메서드에게 책임을 전가했다.
이 divide 메서드를 호출한 main 메서드에서 try catch 문을 통해 예외 처리를 진행했다.
정리하자면,
throw는 강제로 예외를 발생시키는 것이며, 개발자의 의도에 따라 강제로 예외를 발생시킬 수 있고, throws는 자신을 호출한 메서드에게 책임을 전가하여 호출한 메서드에서 예외 처리를 하도록 강요하는 것이다.
제목과 분문을 빈 행으로 구분한다.
제목을 50글자 내로 제한한다.
제목 첫 글자는 대문자로 작성한다.
제목 끝에는 마침표를 넣지 않는다.
제목은 명령문을 사용하며 과거형을 사용하지 않는다.
본문의 각 행은 72글자 내로 제한한다.
어떻게 보다는 무엇과 왜를 설명한다.
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
feat
(feature) : 새로운 기능 추가
fix
(bug fix) : 버그 수정
docs
(documentation) : 문서 관련 내용
style
(formatting, missing semi colons, …) : 스타일 변경
refactor
: 코드 리팩토링
test
(when adding missing tests) : 테스트 관련 코드
build
: 빌드 관련 파일 수정
ci
: CI 설정 파일 수정
perf
: 성능 개선
chore
(maintain) : 그 외의 수정
명령형 현제 시제를 사용해야합니다. -> changed, changes가 아닌 change를 사용❗
첫 글자는 대문자가 아닌 소문자로 사용합니다.
문장 끝에 마침표(.)를 붙이지 말아야 합니다.
명령형과 현제 시제를 사용해야합니다.
변화에 대한 이유와 이전코드와 이후 코드의 차이점을 포함시켜야 합니다.
모든 주요 변경 사항
변경 사항에 대한 설명 (description of the change)
변경사유 (justification)
마이그레이션 참고 사항 (migration notes) 과 함께 footer에 언급되어야 합니다.
BREAKING CHANGE: isolate scope bindings definition has changed and
the inject option for the directive controller injection was removed.
To migrate the code follow the example below:
Before:
scope: {
myAttr: 'attribute',
myBind: 'bind',
myExpression: 'expression',
myEval: 'evaluate',
myAccessor: 'accessor'
}
After:
scope: {
myAttr: '@',
myBind: '@',
myExpression: '&',
// myEval - usually not useful, but in cases where the expression is assignable, you can use '='
myAccessor: '=' // in directive's template change myAccessor() to myAccessor
}
The removed `inject` wasn't generaly useful for directives so there should be no code using it.
Closes #<이슈번호>
와 함께 기록해야합니다.이슈가 하나인 경우
Closes #234
이슈가 여러개인 경우
Closes #123, #245, #992
feat($browser): onUrlChange event (popstate/hashchange/polling)
Added new event to $browser:
- forward popstate event if available
- forward hashchange event if popstate not available
- do polling when neither popstate nor hashchange available
Breaks $browser.onHashChange, which was removed (use onUrlChange instead)
fix($compile): couple of unit tests for IE9
Older IEs serialize html uppercased, but IE9 does not...
Would be better to expect case insensitive, unfortunately jasmine does
not allow to user regexps for throw expectations.
Closes #392
Breaks foo.bar api, foo.baz should be used instead
feat(directive): ng:disabled, ng:checked, ng:multiple, ng:readonly, ng:selected
New directives for proper binding these attributes in older browsers (IE).
Added coresponding description, live examples and e2e tests.
Closes #351
style($location): add couple of missing semi colons
docs(guide): updated fixed docs from Google Docs
Couple of typos fixed:
- indentation
- batchLogbatchLog -> batchLog
- start periodic checking
- missing brace
feat($compile): simplify isolate scope bindings
Changed the isolate scope binding options to:
- @attr - attribute binding (including interpolation)
- =model - by-directional model binding
- &expr - expression execution binding
This change simplifies the terminology as well as
number of choices available to the developer. It
also supports local name aliasing from the parent.
BREAKING CHANGE: isolate scope bindings definition has changed and
the inject option for the directive controller injection was removed.
To migrate the code follow the example below:
Before:
scope: {
myAttr: 'attribute',
myBind: 'bind',
myExpression: 'expression',
myEval: 'evaluate',
myAccessor: 'accessor'
}
After:
scope: {
myAttr: '@',
myBind: '@',
myExpression: '&',
// myEval - usually not useful, but in cases where the expression is assignable, you can use '='
myAccessor: '=' // in directive's template change myAccessor() to myAccessor
}
The removed `inject` wasn't generaly useful for directives so there should be no code using it.
개발을 하면서 내가 짠 코드들을 머릿속으로 온전히 이해하기가 쉽지 않다.
그리고 개발이 시작하기 전, 끝난 이후에 구현한 것에 대한 클래스 다이어그램을 직접 그리는 시간이 오래 걸리는 경우가 있다.
이런 경우 ‘IntelliJ에서 제공하는 다이어그램 기능을 쓰면 시각적인 이해 + 시간 절약
이 되지 않을까?’ 하는 마음으로 해당 포스팅을 작성하게 되었다.
다리 건너기
를 예시로 가져왔다.이 글의 사진과 내용은 공룡책 과 컴퓨터학부 수업인 운영체제 강의자료를 기반으로 작성했습니다.
멀티-레벨 큐(MLQ)
MLQ
란 준비 큐를 여러 개로 분할해 관리하는 스케줄링 기법을 말한다.
즉 프로세스들이 CPU를 기다리기 위해 한 줄로 서는 것이 아니라 여러 줄로 서는 것이다.
MLQ는 일반적으로 성격이 다른 프로세스들을 별도로 관리하고, 프로세스의 성격에 맞는 스케줄링을 적용하기 위해 ready queue를 별도로 두게 된다.
미래를 예측하기 위해 과거를 배우는 스케줄러이다.
ML(F)Q는 다수의 개별 queue를 유지한다.
Rule 1
: Run-time이 짧은 job에게 우선순위(priority)를 부여한다.
Rule 2
: 만약 우선순위가 같으면, 라운드 로빈 스케줄링(RR)을 사용한다.
MLQ는 관찰된 동작에 따라 작업의 우선순위를 변경한다.
Example 동작 :
job은 I/O를 기다리는 동안 CPU를 반복적으로 양도한다.
대화형(interative) 프로세스의 동작은 다음과 같습니다.
우선순위를 높게 유지(단시간 슬라이스 포함) -> 응답 시간 향상
job이 장시간 동안 CPU를 집중적으로 사용한다.
일괄(batch) 작업의 동작은 다음과 같습니다.
우선순위 감소(긴 시간 슬라이스 포함) -> 소요 시간 단축
이러한 방식으로 MLQ는 프로세스가 실행될 때 프로세스에 대해 학습하고, 따라서 job의 기록을 사용하여 미래의 동작을 예측합니다.
멀티레벨 피드백 큐(MLFQ)
MLFQ
는 CPU를 기다리는 프로세스를 여러 queue에 줄 세운다는 측면에서 MLQ와 동일하나, 프로세스가 하나의 queue에서 다른 queue로 이동 가능하다는 점이 다르다.