2009-12-21 4 views
1

OUT 매개 변수를 반환하는 프로 시저가 있습니다. 모든 확인을가는 경우 매개 변수가 0이 될 것이다PL SQL - OUT 매개 변수로 SQLCODE를 반환합니까?

procedure foo (in_v IN INTEGER, out_v OUT integer) 
BEGIN 
... 
EXCEPTION 
    WHEN OTHERS THEN 
    --sh*t happend 
    out_v := SQLCODE; 
END 

및 <> 0 추악한 일이 발생합니다.

이제 sh * t가 발생하면 예외가 발생합니다.

OUT 매개 변수에 SQLCODE 값을 지정하는 것이 좋습니까? 아니면이게 코드 냄새를 고려한 것인가? 나는 프로그래밍 커뮤니티에서 추방 될 것인가?

미리 감사드립니다.

+0

안녕하세요! 이게 당신의 질문을 해결 했나요? 내 대답이 유용하다고 생각되면 동의하고 녹색 체크 박스를 선택하십시오. TIA, roland –

+0

나는 생각했다. : D – Tom

답변

10

오류에 대한 추가 처리가없는 경우이를 권고 할 것입니다. 이 접근 방식은 각 호출자가 out 매개 변수의 값을 조사해야하는 것입니다. 그리고 호출자가 그것을 잊어 버리면 심각한 문제가 처음에 알려지지 않고 다른 곳에서 문제를 디버그하기가 어려울 수 있습니다.

여기에서 OTHERS를 단순히 잡으지 않으면 호출자가 명시 적으로 잡아야한다는 것을 확인할 수 있습니다. 디버거가 훨씬 쉽고 간편합니다.

+0

또한 오류 메시지에서 많은 정보를 잃습니다 (예 : 오류의 원인과 관련된 열 이름이나 줄 번호를 제공함). –

4

좋든 싫든 당신이 달성하고자하는 것에 달려 있다고 생각합니다. 어떤 문제를 해결하려고합니까, 아니면 어떤 요건을 충족하려고합니까?

오류가있는 일반적인 동작은 정상적으로 작동하는 동안 발생할 것으로 예상되는 동작을 정상적으로 처리하고 발생시킬 것으로 기대하지 않는 동작을 정상적으로 처리하는 것이므로 이상하게 보입니다.

2

괜찮 았지만 추천하지 않습니다. 이렇게하면 호출 코드가 비표준 오류 처리를 수행하게됩니다. 코드를 호출하는 유일한 사람이라면 오류 코드를 확인하는 것이 좋습니다. 그러나 여러 프로그래머가있는 대규모 시스템에서 코딩하는 경우 필자는 동료 프로그래머에게 친절하고 해당 언어에서 지원하는 표준 예외 처리 방법을 따라야한다고 생각합니다.

해당 경로로 이동하기로 결정한 경우 오류 텍스트없이 SQLERRM을 다시 전달하면 오류 코드 만 표시됩니다. 수년간 타사 소프트웨어에서 수백 가지 응용 프로그램 오류가 발생하여 "-20001"을 포착 한 후 SQLERRM은 종종 중요합니다.

0

이 코딩 스타일은 여러 가지 이유로 좋지 않습니다.

첫째, 오류 및 예외를 혼합하는 것은 나쁜 습관이고, 더 나쁜 관행은 반환 값과 예외를 혼합하는 것입니다. 예외는 예외적 인 상황 - 메모리 부족 문제, 변환 문제 등과 같은 정상적인 프로그래밍으로는 예상치 못한 상황 - 모든 호출 사이트에서 핸들러를 작성하고 싶지 않지만 어느 수준에서 처리해야하는 상황 -을 추적하기위한 것입니다.

코딩 스타일의 두 번째 걱정 측면은 예외가 발생하면 코드가 호출자에게 잘못된 신호가 있음을 알리고 SQLCODE를 제외한 모든 예외 정보를 버리게된다는 것입니다.