try catch 문구가 좋은가요?
ITOOjava 5.0 코드 검색 중 세부 사항이 하나 있는데, Try catch는 사용을 권장하지 않습니다. 만약 사용한다면 왜 그런지 이것에 대해 진행합니다.
작은 총결산
한마디로
try catch 메커니즘이 아주 좋습니다.try catch가 좋지 않은 것 같아. 아직 그녀의 좋은 점을 발견하지 못했나 봐!
2. 상세한 설명:
1.절차가 건장해야 하며, 반드시 오타 신고 메커니즘을 설계해야 한다.
가장 오래되고 가장 흔히 볼 수 있는 것이다. 예를 들어:
bool CreateFile( );
// false, true。
//파일 생성에 실패하면 false를 반환하고 그렇지 않으면true를 반환합니다.
이런 오보 방식은 분명히 좋지 않다.오류가 발생한 구체적인 원인을 제시하지 않았기 때문이다.
2. 개선: 하나의 함수나 과정은 서로 다른 원인으로 인해 오류가 발생할 수 있으므로 오류 보고 메커니즘은 반드시 이러한 오류 원인을 구분한 후에 보고해야 한다.
예를 들면 다음과 같습니다.
<span style="font-size:18px;">int CreateFile():
// 1.
// , , -1。
// , , -2。
// , , -3。</span>
이렇게 보면 [1]보다 낫고 적어도 비교적 구체적인 실패 원인을 지적했지만 아직 부족하다.
3.많은 경우 함수는 상세한 원인을 문자열로 되돌려야 한다.
<span style="font-size:18px;">class Result
{
....int State;// 【2】
....string ErrorMessage;// , , , 。
}
Result CreateFile();
// , Result,State 1,ErrorMessage null。
// , , Result,State -1,ErrorMessage " 【guest】 【C:\】 。 , 。"。
// , , Result,State -2,ErrorMessage " 【C:\abc.txt】 。 , :arg_overwrite = true"。
// , , Result,State -3,ErrorMessage " , chkdsk 。"。</span>
4.나는 개인적으로 위의 이런 방식을 완전하고 아름답게 추앙한다.그러나 이런 절차는 정상적인 코드와 혼합되기 쉬워 구분하기 어렵다.따라서 Java, C# 등은 try catch라는 특수한 방식을 설계했다.
void CreateFile()
// 。
// , , AccessException, Exception Msg " 【guest】 【C:\】 。 , 。"。
// , , FileExistedException, Exception Msg " 【C:\abc.txt】 。 , :arg_overwrite = true"。
// , , TimeoutException, Exception Msg " , chkdsk 。"。
이를 통해 알 수 있듯이 상술한 메커니즘은 실제적으로 서로 다른 Exception으로 [3]의 State를 대체했다.
이 메커니즘은 외부에서 사용할 때 다음과 같습니다.
try
{
....CreateFile( "C:\abc.txt" );
}
catch( AccessException e )
{
....// 【 】
}
catch( FileExistedException e )
{
....// 【 】
}
catch( TimeoutException e )
{
....// 【 】
}
【3】, 【3】 , 。
5. 요약하면 저는 개인적으로 [3]과 같은 과정을 향한 쓰기를 좋아합니다.하지만 대상을 향한 친구를 좋아하는 친구들이 많으니 [4]의 글씨를 더 좋아할 것 같다.그러나
[3]와 [4]는 모두 같다.이 두 가지 메커니즘은 모두 우수한 오류 처리 메커니즘이다.
6. 이론을 다 말하고 본론으로 돌아가서 질문: 왜try catch를 사용하지 않습니까?
해답: 어떤 사람들은 아직 익숙하지 않을 수도 있고, 초보자일 수도 있기 때문에 코드를 이렇게 쓸 수도 있다.
<span style="font-size:18px;">void CreateFile( )
// , Exception, Msg 。
, :
try
{
....CreateFile( "C:\abc.txt" );
}
catch( Exception e )
{
....//
}</span>
잘못을 저지른 후, 그것이 잘못되었다는 것만 알 뿐, 무슨 원인이 잘못을 초래했는지 모른다.이것은 같다.
그리고CreateFile은 [4]의 규칙에 따라 설계되었음에도 불구하고 채소새는 바깥쪽에서 이렇게 사용한다.
<span style="font-size:18px;">try
{
....CreateFile( "C:\abc.txt" );
}
catch( Exception e )
{
....//
....throw Exception( " " )
}</span>
이런 상황에서 이 코드를 호출했거나 사용자가 이 오류 정보를 보았을 때 오류가 발생했다는 것만 알 수 있을 뿐 오류의 원인을 알 수는 없다.이
[1]과 동일합니다.
이러한 원인 때문에 초보자와 사용자들이 생각하지 못했을 수도 있다. 이 문제의 원인은 숙련도가 부족하고 코드맵을 쓰는 것이 간단하기 때문이다.그들은 도리어
try catch 메커니즘이 안 돼서요.
그래서 이런 상황에서 많은 사람들이trycatch를 사용하는 것을 권장하지 않는다고 생각할 것이다.
2. 경험 총결산:
그런 언어인지 똑똑히 물어보는 게 좋을 거야.Try Catch를 언어별로 처리하는 메커니즘이 다르기 때문에 답변도 다를 수 있다.
(1) C++의 경우:
try catch를 사용하지 않는 것을 추천합니다. Windows API 같은 HResult를 사용해서 오류를 되돌려 주는 것을 추천합니다. 왜냐하면 try catch가 이미 있는 코드에 있기 때문입니다.
위에 추가cost를 추가합니다. 이 추가cost는throw exception 때만 있는 것이 아니라try catch block 안의 줄마다 있습니다.
코드에 모두 있습니다. 이것도try catch를 사용하는 것을 권장하지 않는 가장 큰 이유입니다.Windows 소스 코드에는 try catch가 없습니다.
, 모두 HResult로 처리합니다.
(2) C#의 경우:
try catch는 사용을 권장합니다. C# 디자인할 때 얻은 C++ try catch의 교훈으로 Try catch로 기존 코드를 직접 감싸서 추가했습니다.
cost는 무시할 수 있지만, 코드가 실행되는 과정에서throw exception이 실행된다면, 이cost는 여전히 매우 크다.그래서 C# 코드에서
중,throw exception은 기본적으로 당신이 이런 의외의 상황이 발생하지 않을 것이라고 생각하는 경우입니다. 그렇지 않으면, 흔히 볼 수 있는 오류라면,throw를 사용하지 않는 것이 좋습니다.
exception.
예를 들어 Java,try catch도 사용을 권장합니다. 이것은 익숙하지 않지만, 설명을 보면,throw exception 때의cost도
아주 작다.
3. 자바 언어에서:
사실 위의 예를 통해 우리는 사용을 권장하지 않는 것이 아니라는 것을 발견했다.남용해서는 안 된다.
여기 Effective Java의 이상한 항목에 대해 아주 잘 알고 있습니다.문제주에게 한번 가보라고 건의하다.나는 여기에서 간단하게 운반할 것이다.부분원
이 문서는 다음과 같습니다.
비정상적인 경우에만 이상 사용
책에서 하나의 예를 제시했다
try {
int i=0;
while (true) {
arr[i]=0;
i++;
}
} catch (IndexOutOfBoundsException e) {
}
이것은 매우 뚜렷한 오류로 이상을 통해 순환을 중단하고 어떤 최적화에 도달하기를 희망한다.사실은 그렇지 않다.
• JVM은 비정상적인 블록의 코드를 거의 최적화하지 않습니다.
• 생성, 배포, 예외 발견 비용이 많이 듭니다.
• 정상적인 스트리밍 배열은 불필요한 경계 검사를 초래하지 않으며 현대의 JVM은 최적화될 것이다
검사된 이상을 불필요하게 사용하지 않도록 하다
'검사된 이상' 은 자바 언어의 좋은 특성이다.반환 코드와 달리, '검사된 이상' 은 프로그램원에게 예외적인 항목을 처리하도록 강요할 수 있다
부품, 프로그램의 신뢰성을 크게 향상시켰다.
그러나 과도한 사용으로 이상이 확인되면 API를 사용하기가 매우 불편하다.만약 한 방법이 검사된 이상을 하나 이상 던진다면, 호출합니다
이 방법의 코드는 하나 이상의catch 문장 블록에서 이 이상을 처리해야 하거나,throws 설명을 통해 이 이상을 제거해야 합니다.통하든 통하든
catch 처리를 하든지throws 성명을 통해 던지든지, 모두 프로그래머에게 무시할 수 없는 부담을 추가합니다.
'검사된 이상'에 적용되려면 두 가지 조건을 동시에 만족시켜야 한다. 첫째, API를 정확하게 사용해도 이상 조건의 발생을 막을 수 없다.일단
예외가 발생하여 API를 사용하는 프로그래머가 유용한 동작으로 프로그램을 처리할 수 있습니다.
이상을 소홀히 하지 말고,
어떤 프로그래머들은 아래의 코드를 쓸 수 있다
<span style="font-size:24px;">try {
...
} catch (SomeException e) {
}
</span>
빈catch 블록은 이상을 제 목적에 이르지 못하게 할 수 있습니다. 이상한 목적은 비정상적인 조건을 처리하도록 강요하는 것입니다.이상을 소홀히 하는 것은 하나를 소홀히 하는 것과 같다
개의 화재 신호가 같다--화재 신호기를 끄면 진정한 화재가 발생할 때 아무도 화재 신호를 보지 못한다.그래서 적어도catch
블록은 왜 이 이상을 무시하는 것이 적합한지 설명하기 위해 설명을 포함해야 한다.
요약:
try catch는 구체적인 언어를 사용하는 것을 권장하는지 여부입니다. 가장 중요한 기준은 기존의 코드 성능에 얼마나 큰 영향을 미치는지입니다.그렇지만
그것의 디자인 측면에서 보면 예상치 못한 상황을 처리하기 위한 것이지만, 당초에 도입되었을 때 각양각색의 원인으로 인해 일부 언어는 성을 위해
네, 추천하지 않아요.
BTW,try catch는 catch(Exception)를 사용하지 않는 것이 좋다. 그러면 먹지 말아야 할 문제를 먹을 수 있다. 예를 들어 C#의 Stack Overflow Exception,
Out OfMemory Exception, Null Reference Exception etc. 이 crash를 사용할 때 App crash,restart를 사용해야 합니다. 이것도 당신을 보호하는 것입니다.
서비스의 좋은 방법
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
vueaxios 요청이 성공했지만catch에 들어간 원인 분석문제:axios 200 상태 코드 (즉 요청 성공) 를 되돌려주고catch 안으로 들어갔습니다. 원인: 1. axios 요청이 완료되면 then의 코드 블록, then 코드 블록에 오류 코드 정보가 존재하면catch...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.