프로그래밍 언어에서 오류가“예외”로 명명 된 이유는 무엇입니까?

나는 실제로 그것에 대해 꽤 오랫동안 생각 해왔다. 나는 영어 원어민이 아니지만 여전히 수년간의 프로그래밍 경험을 가지고 있으며 항상 나에게 이것을 물었습니다. 오류로 이름이 Exception 인 이유는 무엇입니까?

PageNotFoundError대신 사용할 수 있습니다 PageNotFoundException.

전혀 오류 일 필요는 없습니다. 페이지가 없다는 사실은 실제 오류보다는 흥미로운 사실 ​​일 수 있습니다. 그들은 거의 항상 오류로 사용되는 것처럼 보입니다. 그러나 때로는 루프에서 벗어나거나 문자열이 유효한 숫자가 아니라는 것을 알려주는 데 사용됩니다. 상당히 정상적인 수익의 일부로 방대한 양의 유용한 데이터를 보유하고 반환하는 데 사용할 수 있습니다. (일부 언어는 예외로 인해 속도가 느리므로이 경우 자주 던지는 것은 나쁜 생각입니다.) 이론상 예외는 단지 "정상 반품을 수행하지 말고 관심있는 사람을 찾을 때까지 통화 스택을 올리십시오"라는 의미입니다. 이것에서. "

널 포인터 예외조차 당신에게 큰 의미가 없을 수도 있습니다. 다른 사람의 코드를 호출 한 다음 폭발 할 가능성이 있다는 것을 알고 널 오류를 알리는 메시지를 인쇄하고 작업을 계속 수행하기 때문에 널 포인터 예외를 포착합니다.

예외 메커니즘이 항상 오류를 알리는 데 사용되는 것은 아닙니다 . 오류를 포함하여 처리 할 별도의 코드 경로가 필요한 일반적인 상황에서는 예외가 발생합니다. 예를 들어, 존재하지 않는 파일 이름을 제공하거나 숫자 필드에 숫자 대신 문자를 입력하는 사용자는 특별한 처리가 필요한 예외적 인 상황이지만 오류는 아닙니다.

Java와 같은 일부 프로그래밍 환경에서는 Error"실제 오류"를보고하기 위해 특수 응용 프로그램이 제공되며, 합리적인 응용 프로그램이 처리하지 않아야하는 상황입니다. 이러한 개체는 예외를 전달하는 데 사용되는 것과 동일한 메커니즘을 사용하여 제공되지만 복구 할 수없는 상황 신호의 특별한 의미를 갖습니다.

그 기원에 대한 어원 학적 연구는 없지만 "오류"라는 용어를 사용하는 것이 모든 상황에서 정확하지는 않다는 것을 이해할 수 있습니다. almostSharepointMaster가 언급했듯이 오류와 예외를 분리 된 엔티티로 생각하는 것이 좋습니다.

고급 프로그래밍 언어를 사용하는 경우 예외는 항상 오류로 인해 발생한다고 가정하는 것이 좋습니다.하지만 dasblinkenlight 와도 동의하지만 예외가 항상 오류의 결과는 아니라는 데 동의합니다. 예를 들어, 예외를 사용하여 스레드를 공동으로 종료합니다.

"예외"라는 용어를 처음 본 것은 80386 어셈블리 매뉴얼에있었습니다. 나는 그것을 볼 때 즉시 자연스럽게 보였다는 것을 기억합니다. 어셈블리에 오류가 없기 때문에 오류가 정확하지 않다고 부르는 것; 단순히 프로세서가 처리 할 수없는 조건이 있습니다 (프로그래머, 사용자 또는 시스템의 오류 인 경우 프로세서는 프로세서와 완전히 무관합니다). 인텔이 실제로 그 용어를 유래했는지 아닌지는 모르겠지만 아마도 ...

일반적으로 Exception은 out_of_range존재하지 않는 벡터 또는 배열의 요소에 액세스 할 때 발생하는 C ++ 의 예외 와 같이 올바르지 않지만 복구 할 수있는 이벤트의 이름을 지정하는 데 사용됩니다 . 분명히 그러한 사건이 정확하지는 않지만 전체 프로그램이 충돌하는 것은 아닙니다.

반면에 오류는 일반적으로 모든 것을 중단 해야하는 이름을 지정하는 데 사용되며 스택 오버플로와 같은 것은 프로그램이 내부적으로 처리 할 수 ​​없으므로 프로그램을 종료 해야하는 이벤트의 예입니다. 다시 말해, 오류는 크지 만 예외는 비교적 작습니다.

이것이 오류 처리의 "진화"와 더 관련이 있다고 생각합니다. C / C ++ (예외 처리가 추가되기 전) 언어에서 함수가 실패하면 반환 값을 통해서만 알 수 있습니다 (예 : HRESULTwin32). 따라서 일반적으로 각 함수 호출의 종료 코드를 잡아서 확인했습니다. 이 접근 방식은 코드를 더 복잡하게 만듭니다. 그리고 종종 개발자는 게으름에서 이러한 검사를 추가하지 않아도됩니다.

예외 처리가 도입되면서 개발자는 이제 오류를 발생시키는 두 가지 옵션 을 갖게되었습니다 . 따라서 "예외"단어는 오류를 "종료 상태"오류와 구별하기 위해 사용되었습니다. 일정 기간이 지나면 코드를 훨씬 쉽게 읽고 유지 관리 할 수 ​​있고 오류 처리 논리를 가질 수있는 단일 장소가있을 수 있기 때문에 예외 처리는 오류를 전파하는 일반적인 방법이되었습니다.

파이썬에서는 ABCError Eg : KeyError, IndexError로 명명됩니다.

http://docs.python.org/library/exceptions.html

그래서 나는 그것이 당신이 사용하는 언어에 달려 있다고 생각합니다.

오류가 발생하면 시스템 또는 현재 실행중인 응용 프로그램이 오류에 대한 정보가 포함 된 예외를 발생시켜보고합니다. 예외가 발생하면 응용 프로그램이나 기본 예외 처리기가 예외를 처리합니다.

오류는 오류를 자세히 설명하는 예외에 영향을 미치므로 모든 것이 예외 인 예외는 아닙니다.

http://msdn.microsoft.com/en-us/library/system.exception.aspx

iOS / Mac 프로그래밍에서는 단일 언어로 예외와 오류가 모두 있습니다.

해당 환경에서 예외는 "복구 불가능"이고 오류는 "복구 가능"입니다.

예를 들면 다음과 같습니다.

• 10 개의 항목이있는 배열이 있고 색인 30에서 항목에 액세스하려고하면 예외입니다. 프로그래밍에 실수를했습니다.
• URL을 다운로드하려고하지만 인터넷에 연결되어 있지 않으면 예상되는 것이며 사용자에게 일종의 메시지를 표시해야합니다.

예외는 일반적으로 앱을 중단시키는 반면, 오류는 일반적으로 반환 nil되고 오류 객체는 참조 메서드 매개 변수로 반환됩니다. try / catch / finally 블록으로 예외를 잡을 수는 있지만이 언어 기능을 사용하지 않는 것이 좋습니다. 어떤 방식 으로든 예외를 복구 할 수 있다면 예외를 전혀 발생시키지 않아야합니다. 대신 오류 객체).

오류는 프로그램 실행에 사라 잘못을 가지고 무언가이다. 종종 이것은 예외 를 제기함으로써 다루어 지지만

• 프로그래머가 예외를 발생 시켜서 오류를 처리하도록 강요하는 것은 없으며
• 프로그래머가 오류가 발생한 경우에만 예외를 발생시키는 것은 없습니다.

오류는 의미 론적 개념입니다. 프로그램과 함께 기대하는 프로그래머 나 사용자가 기대와 현실의 차이를 설명하기 위해 적용합니다. 루틴 만이 오류 상태인지 여부를 개인 만이 말할 수 있습니다.

예외는 구문 개념입니다. 프로그램의 기능에 대한 모든 사람의 기대와 무관하게 프로그램 자체의 무언가입니다. 루틴은 누군가의 생각에 관계없이 예외를 발생 시키거나 발생시키지 않습니다.

예외와 오류가 다릅니다.

예외는 파일을 열려고하는데 존재하지 않는 것처럼 프로그램이 극복 할 수있는 상황이며, 오류는 프로그램이 디스크 장애 나 RAM 장애와 같이 아무 것도 할 수없는 상황입니다.

예외 발생 및 처리는 제어 흐름 기능이며 예외 이름은 의도 된 사용법을 따라야합니다. 코드 및 API 디자이너는 우수하고 일관된 이름 지정 체계를 찾아야합니다.

따라서 귀하의 질문에 대한 답변은 상황과 관점에 달려 있습니다.

예외는 오류의 일반화로 발전했습니다. 예외 메커니즘을 포함하는 최초의 프로그래밍 언어는 1970 년대 초에 리스프했다. 가브리엘과 스틸 의 언어 진화 패턴에 좋은 요약이 있습니다.. 예외 (아직 예외라고 불림)는 오류가 발생할 경우 프로그램의 동작을 지정해야 할 필요성에서 발생했습니다. 한 가지 가능성은 프로그램을 중단하는 것이지만 항상 도움이되는 것은 아닙니다. Lisp 구현은 전통적으로 오류에 대해 디버거를 입력 할 수있는 방법이 있었지만 프로그래머는 때때로 프로그램에 오류 처리를 포함하려고했습니다. 따라서 1960 년대 Lisp 구현은“이 작업을 수행하고 오류가 발생하면 대신 수행하십시오”라고 말할 수있었습니다. 원래 오류는 원시 함수에서 비롯되었지만 프로그래머는 프로그램의 일부를 건너 뛰고 오류 처리기로 건너 뛰기 위해 의도적으로 오류를 트리거하는 것이 편리하다는 것을 알았습니다.

1972 년, 리스프에서 예외 처리의 현대적인 형태는 MacLisp에 출연 : throw와 catch. 소프트웨어 보존 그룹 을 포함한 초기 리스프 구현에 많은 자료를 나열 데이비드 달에 의해 MACLISP 참조 설명서 개정 0 . 기본 요소 catch및 throw§5.3 p.43에 문서화되어 있습니다.

catch구조화 된 비 로컬 종료를 수행하기위한 LISP 기능입니다. (catch x)평가 x중에 평가 x (throw y)해야하는 경우 추가 평가없이 catch즉시 반환 한다는 점을 제외하고 값을 평가 하고 반환합니다 .yx

catch또한 평가되지 않은 econd 인수와 함께 사용될 수 있으며 중첩 된 캐치를 구별하기위한 태그로 사용됩니다. (…)

throw함께 사용되는 catch구조화 된 출구 비 로컬 메커니즘.

(throw x)x값을 평가 하고 가장 최근의 값으로 되돌립니다 catch.

(throw x <tag>)레이블이 있거나 레이블이없는 x가장 최근 의 값을 다시 반환합니다 .catch<tag>

로컬이 아닌 제어 흐름 에 중점을 둡니다 . 그것은 goto (위쪽 전용 goto)의 형태이며 jump 라고도 불립니다 . 은유는 프로그램의 한 부분이다 발생 예외 핸들러로 반환 값을 상기 예외 핸들러 를 잡는 그 값을 반환 그것.

오늘날 대부분의 프로그래밍 언어는 예외 객체에 태그와 값을 묶고 잡기 메커니즘과 처리 메커니즘을 결합합니다.

예외가 반드시 오류는 아닙니다. 그것들은 예외에 대한 핸들러에 도달 할 때까지 탈출하여 코드 블록과 주변 블록에서 빠져 나갈 수있는 방법입니다. 그러한 것이 직관적 인 의미에서 "오류"로 간주되는지 여부는 주관적입니다.

일부 언어는 "오류"와 "예외"라는 용어를 구별합니다. 예를 들어, 일부 리스프 (Lisp) 방언은 throw예외 (사용자에 대한 제어 흐름, 어떤 것이“잘못되었다는 것을 나타내지 않는 방식으로 로컬이 아닌 출구를 수행하는 것을 의미 함”)와 signal오류를 발생시키는 것 ( 문제가 발생하여 디버그 이벤트가 발생할 수 있습니다.

다른 프로그래밍 언어 구현에서 다르게 해석됩니다. dasblinkenlight가 말했듯이 그것은 Error와 Exception 사이의 경계를 갖는 Java 관점입니다. 많은 프로그래밍 언어에서 예외는 위반이 처리 될 수 있고 가능한 최고 코드 모듈로 전달되도록 버블 링 될 수 있습니다. 오류는 일반적으로 언어의 런타임 컨테이너가 처리하는 상황이며 대부분의 경우 실행을 중지합니다.

오류는 항상 오류입니다. 예외는 현재 컨텍스트의 오류입니다. 즉, 예외는 상황에 따라 다릅니다. 예외의 예는 정수 "1"에 아스키 "a"를 추가하는 것입니다. "+!"와 같은 정의되지 않은 연산자를 사용하는 것과 같은 오류가있을 수 있습니다. 대부분의 언어로.

일부 언어를 사용하면 실제로 원하는 작업을 수행 할 수 있습니다.