예외를 버그라고한다면, 예외 대신 우선 버그라고 부르지 않겠습니까?
코드에서 예외라고하며 발생하자마자 버그라고합니다. 그렇다면 왜 먼저 버그라고 부르지 않습니까?
답변이나 의견을 보내 주셔서 감사합니다.
예외를 버그라고한다면, 예외 대신 우선 버그라고 부르지 않겠습니까?
코드에서 예외라고하며 발생하자마자 버그라고합니다. 그렇다면 왜 먼저 버그라고 부르지 않습니까?
답변이나 의견을 보내 주셔서 감사합니다.
답변:
글쎄, 그것은 매우 간단합니다 : 모든 예외가 버그는 아닙니다 (그리고 마찬가지로 모든 버그가 예외로 나타나는 것은 아닙니다).
USB 드라이브에서 파일을 읽고 누군가가 드라이브를 소켓에서 빼 내면 버그가 아닌 예외의 예입니다. 예외가 발생합니다 (예외를 지원하는 대부분의 언어에서). 그러나 코드의 버그는 아닙니다.
반대로, 버그는 계산 오류 또는 무언가로 나타날 수 있습니다. 당신은 여전히 답을 얻습니다. 정답이 아닙니다.
그러나 스택 맨 위로가는 예외 는 버그 일 가능성 이 높습니다 . 위의 USB 예제에서, 당신은 그 예외를 잡아서 "더 이상 연결되어 있지 않기 때문에 파일을 읽을 수 없습니다"라는 멋진 오류를 사용자에게 제시 할 수있을 것입니다. 또는 뭔가. 방금 IOException
펑키 한 오류 코드를 제시 하면 버그입니다. 그러나 예외 자체는 아닙니다.
평범하고 간단한 예외는 (항상) 버그가 아닙니다!
예외적 인 상황이 발생하면 예외가 발생합니다. 하드 드라이브에 문제가있어 파일을 쓸 수없는 경우에는 버그가 아닙니다. 하드웨어의 고장입니다.
버그는 일반적으로 잘못된 프로그래밍의 결과입니다. 응용 프로그램이 프로그래밍 오류로 인해 예상치 못한 작업을 수행하는 경우 이는 버그입니다.
그들은 같은 것이 아닙니다.
버그는 소프트웨어의 조각의 의도하지 않은 동작입니다 : 소프트웨어가 어떻게해야되는 일을하지 않습니다. 버그는 평범한 오타에서 논리적 오류, 부적절한 기능 사양에 이르기까지 모든 수준의 소프트웨어 개발에 적용 할 수 있습니다.
예외는 대조적으로, 신호 및 상기 조건을 처리하기 위해 사용되는 언어 구조,보다 구체적으로는, 통상 동작으로부터 벗어난, 프로그램의 비정상적인 조건 중 하나를 참조하거나 할 수있다.
예외가 발생한다는 사실은 버그의 징후 일 수 있지만 종종 그렇지 않습니다. 예를 들어, URL에서 문서를 다운로드하여 로컬로 처리해야하는 응용 프로그램은 원격 서버가 다운 될 때 예외를 발생시킬 수 있습니다. 예외를 올바르게 처리하고 복구하면 버그가 없습니다.
반대로, 버그가 있다고해서 반드시 예외로 나타나는 것은 아닙니다. 응용 프로그램은 입력 한 데이터를 데이터베이스에 저장하지 않고 자동으로 버릴 수 있습니다. 예외는 발생하지 않지만 여전히 버그입니다.
소프트웨어 버그는 컴퓨터 프로그램 또는 시스템의 오류, 결함, 실수, 실패 또는 결함을 설명하는 데 사용되는 일반적인 용어로, 잘못되거나 예기치 않은 결과가 발생하거나 의도하지 않은 방식으로 동작합니다. 라벨에 철자가 잘못되었을 수도 있습니다.
예외는 버그와 다릅니다. 각 종류의 예외 (액세스 위반, 스택 오버플로 등)는 "첫 번째 기회"또는 "두 번째 기회"예외로 디버거에 발생할 수 있습니다. 첫 번째 예외는 오류 처리기로 올바르게 처리되지 않으면 치명적이지 않은 정의입니다.이 시점에서 두 번째 예외 (디버거 만 처리 할 수있는 예외)로 다시 발생합니다.
디버거가 두 번째 기회 예외를 처리하지 않으면 응용 프로그램이 종료됩니다.
모든 예외는 버그가 아닙니다. 모든 버그가 예외인지 여부는 논쟁의 주제 일 수 있습니다.
예외는 정상적인 또는 예상되는 응용 프로그램 흐름의 일부가 아닌 이벤트라고 말할 수 있습니다. 이러한 이벤트는 버그가 본질적으로 잘못된 코드의 결과 (잘못된 계산과 같은) 인 코드 작성 방법과 무관합니다.
다음은 예외 처리가 버그가 될 수있는 방법에 대한 예입니다.
외부 저장 장치에 일부 데이터를 쓰는 프로그램이 있다고 가정 해 봅시다. 외부 저장 장치를 쓰는 동안 플러그가 뽑혔거나 추락되었거나 파손될 수 있습니다 (이유가 무엇이든). 이제는 예외적입니다. 이제 프로그래밍 언어가 예외적 인 처리를 지원하는지 여부에 관계없이이 이벤트로 인해 프로그램이 충돌하거나 오작동하는 경우 버그입니다. . 그러나 프로그램이 프로세스를 정상적으로 중단하면 사용자에게 알리십시오 (즉, 실행을 처리하십시오). 이것은 분명히 버그가 아닙니다.
캐치 메카니즘 프로그래밍 언어가 제공하는 try catch 메카니즘은 본질적으로 예기치 않은 이벤트를 처리 할 수있는 도구입니다.
개요 : 예외는 나쁜 결과의 증거이며, 버그는 나쁜 결과의 원인 중 일부입니다. 문제 (해결해야 할 문제)는 예외가 아니며 문제의 원인은 예외입니다.
Resoning : 버그 제품의 설계 및 구현에 결함이있다 (소프트웨어에 한정되는 것은 아니다). 예를 들어, 잘못된 사양이나 간단한 빌드 오류로 인해 적절한 등급의 릴레이 (시간 / 감도 / 신뢰성 / 용량)를 사용하지 않는 경우가 있습니다. 예외는 (내가 감히 '기대'?) 동작을, 예를 들어, 차량의 제어의 손실을 운전하는 동안 예측에서 실제 / 실행 시간 편차이다.
분명히 1)의 예제가 2)의 예제로 이어질 수 있으므로 버그로 인해 예외가 발생할 수 있습니다. 그러나 운전자가 뇌졸중을 일으켰 기 때문에 차량 제어력 상실과 같은 버그로 인해 모든 예외가 발생하는 것은 아닙니다.
이 질문이 현상금으로 재개되었으므로 2003 년부터 "예외 또는 버그?"라는 CUJ 기사를 언급 할 수 있는데, 이는 OP의 질문과 정확히 일치하는 것으로 보입니다.
기본적으로이 기사에서는 "버그"및 "예외"(예제 제공)라는 용어를 정의하고 각각을 다루기위한 전략을 제안합니다.
이 기사에서는 버그를 "처리"하는 대신 어설 션으로 플래그를 지정합니다. 반대로, 실제 예외는 코드를 통한 처리가 필요합니다 (예외 던지기 / 잡기 가능).
요점은 버그가 예외 와 정확히 반대되는 전략을 요구한다는 것입니다.
위에서 언급 한 기사는 Dr.Dobb 's ( http://www.drdobbs.com/an-exception-or-a-bug/184401686) 에서 제공합니다.