예외를 지원하지 않는 언어에서 0으로 나누기를 처리하는 방법은 무엇입니까?

일부 비즈니스 요구 사항을 해결하기 위해 새로운 프로그래밍 언어를 개발하는 중입니다.이 언어는 초보자 사용자를 대상으로합니다. 따라서 언어에서 예외 처리를 지원하지 않으므로 추가해도 예외를 사용할 것으로 기대하지 않습니다.

나누기 연산자를 구현 해야하는 시점에 도달했으며 0으로 나누기 오류를 가장 잘 처리하는 방법이 궁금합니다.

이 사례를 처리 할 수있는 방법은 세 가지 뿐인 것 같습니다.

1. 오류를 무시하고 0결과로 생성 하십시오. 가능하면 경고를 기록합니다.
2. NaN숫자의 가능한 값으로 추가 하되 NaN, 언어의 다른 영역에서 값 을 처리하는 방법에 대한 질문 을합니다.
3. 프로그램 실행을 종료하고 심각한 오류가 발생한 경우 사용자에게보고하십시오.

옵션 # 1이 유일한 합리적인 해결책 인 것 같습니다. 이 언어는 야간 크론으로 논리를 실행하는 데 사용되므로 옵션 # 3은 실용적이지 않습니다.

0으로 나누기 오류를 처리하는 대안은 무엇이며 옵션 # 1을 사용할 때의 위험은 무엇입니까?

오류를 무시하는 것은 위험한 안티 패턴이기 때문에 # 1에 강력히 권합니다. 분석하기 어려운 버그로 이어질 수 있습니다. 나누기 결과를 0으로 0으로 설정하면 아무런 의미가 없으며, 무의미한 값으로 프로그램을 계속 실행하면 문제가 발생합니다. 특히 프로그램이 무인으로 실행될 때. 프로그램 인터프리터가 프로그램에 오류가 있음을 발견하면 (0으로 나누기는 거의 항상 설계 오류 임),이를 중단하고 모든 것을 그대로 유지하는 것이 일반적으로 데이터베이스를 쓰레기로 채우는 것보다 선호됩니다.

또한이 패턴을 철저히 따르는 데 성공하지 못할 수도 있습니다. 조만간 메모리 부족 또는 스택 오버플로와 같이 무시할 수없는 오류 상황이 발생하고 프로그램을 종료하는 방법을 구현해야합니다.

옵션 # 2 (NaN 사용)는 약간의 작업이지만 생각만큼 많지는 않습니다. 다른 계산에서 NaN을 처리하는 방법은 IEEE 754 표준에 잘 설명되어 있으므로 통역사가 작성한 언어로 수행 할 수 있습니다.

그건 그렇고 : 프로그래머가 아닌 사람이 사용할 수있는 프로그래밍 언어를 만드는 것은 1964 년 이후 (Dartmouth BASIC) 시도한 것입니다. 지금까지 우리는 실패했습니다. 어쨌든 행운을 빈다.

1-오류를 무시 0하고 결과로 생성 하십시오. 가능하면 경고를 기록합니다.

그건 좋은 생각이 아니다. 조금도. 사람들은 그것에 따라 시작하고 그것을 고쳐야한다면 많은 코드를 깨뜨릴 것입니다.

2- NaN숫자의 가능한 값으로 추가 하되 NaN, 언어의 다른 영역에서 값 을 처리하는 방법에 대한 질문 을합니다.

다른 언어의 런타임이 수행하는 방식으로 NaN을 처리해야합니다. 추가 계산을 수행하면 NaN이 생성되고 모든 비교 (NaN == NaN도 포함)는 false를 생성합니다.

나는 이것이 수용 가능하지만 반드시 새로운 친근한 것은 아닙니다.

3-프로그램 실행을 종료하고 심각한 오류가 발생한 경우 사용자에게보고하십시오.

이것이 내가 생각하는 최고의 솔루션입니다. 이러한 정보를 보유한 사용자는 0을 처리 할 수 ​​있어야합니다. 특히 밤에 한 번 실행하려는 경우 테스트 환경을 제공해야합니다.

네 번째 옵션도 있습니다. 나누기를 삼항 연산으로 만듭니다. 이 두 가지 중 하나가 작동합니다.

• div (분자, 분자, alternative_result)
• div (분자, 분자, alternative_denumerator)

극단적 인 편견으로 실행중인 응용 프로그램을 종료하십시오. (적절한 디버그 정보를 제공하는 동안)

그런 다음 제수가 0 일 수있는 조건 (사용자가 입력 한 값 등)을 식별하고 처리하도록 사용자를 교육하십시오.

Haskell (및 스칼라와 유사)에서 예외를 던지거나 널 참조를 리턴하는 대신 랩퍼 유형 Maybe을 Either사용할 수 있습니다. 으로 Maybe사용자 그가 얻은 값이 "빈"의 경우 테스트 할 수있는 기회를 가지고, 또는 그는 "풀기"기본값을 제공 할 수 있습니다. Either비슷하지만 문제가있는 경우 문제를 설명하는 개체 (예 : 오류 문자열)를 반환하는 데 사용할 수 있습니다.

다른 답변은 이미 아이디어의 상대적인 장점을 고려했습니다. 나는 또 다른 것을 제안합니다 : 변수 가 0 일 수 있는지 여부를 결정하기 위해 기본 흐름 분석을 사용하십시오 . 그런 다음 잠재적으로 0 인 변수로 나누기를 허용하지 않을 수 있습니다.

x = ...
y = ...

if y ≠ 0:
  return x / y    // In this block, y is known to be nonzero.
else:
  return x / y    // This, however, is a compile-time error.

또는 변하지 않는 변수를 설정하는 지능적인 어설 션 함수를 사용하십시오.

x = ...
require x ≠ 0, "Unexpected zero in calculation"
// For the remainder of this scope, x is known to be nonzero.

이는 정의되지 않은 작업을 완전히 없애는 런타임 오류를 발생시키는 것만큼이나 좋지만, 잠재적 인 오류가 노출되기 위해 코드 경로에 도달 할 필요가 없다는 이점이 있습니다. 불변량을 추적하고 확인하기 위해 중첩 된 타이핑 환경으로 프로그램의 모든 분기를 평가하여 일반적인 유형 검사와 매우 유사합니다.

x = ...           // env1 = { x :: int }
y = ...           // env2 = env1 + { y :: int }
if y ≠ 0:         // env3 = env2 + { y ≠ 0 }
  return x / y    // (/) :: (int, int ≠ 0) → int
else:             // env4 = env2 + { y = 0 }
  ...
...               // env5 = env2

또한 null언어에 그러한 기능이있는 경우 자연스럽게 범위와 검사 까지 확장됩니다 .

숫자 1 (삽입 할 수없는 0 삽입)은 항상 잘못되었습니다. # 2 (전파 NaN)와 # 3 (프로세스 중단) 중에서 선택하는 것은 컨텍스트에 따라 다르며 Numpy와 마찬가지로 전역 설정이 이상적입니다.

하나의 큰 통합 계산을 수행하는 경우 NaN을 전파하는 것은 결국 전체 계산에 영향을 미쳐서 영향을 미치기 때문에 나쁜 생각입니다. 아침에 결과를보고 모두 NaN임을 알면 d 결과를 버리고 어쨌든 다시 시작해야합니다. 프로그램이 종료되면 한밤중에 전화를 받고 문제를 해결하는 것이 더 좋았을 것입니다. 적어도 시간 낭비라는 말입니다.

지도 축소 또는 난해한 병렬 계산과 같이 대부분 독립적 인 작은 계산을 많이하고 NaN으로 인해 사용할 수없는 비율을 허용 할 수있는 것이 가장 좋은 방법 일 것입니다. 프로그램을 종료하고 99 %를 잘못하고 1 %로 잘못되고 0으로 나눠서 유용하고 유용한 것은 실수 일 수 있습니다.

NaN과 관련된 다른 옵션 : 동일한 IEEE 부동 소수점 사양은 Inf 및 -Inf를 정의하며, NaN과 다르게 전파됩니다. 예를 들어, Inf> any number 및 -Inf <any number는 제로가 작은 숫자로 가정되어 0으로 나누기가 발생하면 원하는 것입니다. 입력이 반올림되고 측정 오류 (예 : 손으로 측정 한 물리적 측정)가 발생하는 경우 두 대량의 차이가 0이 될 수 있습니다. 0으로 나누지 않으면 큰 숫자를 얻었을 것입니다. 이 경우 In 및 -Inf는 올바른 결과입니다.

공식적으로도 정확할 수 있습니다. 확장 된 영역에서 작업 중이라고 말하면됩니다.

3. 프로그램 실행을 종료하고 심각한 오류가 발생한 경우 사용자에게보고하십시오.

[이 옵션]은 실용적이지 않습니다…

물론 실용적이다 : 실제로 이해되는 프로그램을 작성하는 것은 프로그래머의 책임이다. 0으로 나누는 것은 의미가 없습니다. 따라서, 프로그래머가 나누기를 수행하는 경우, 제수가 제로가 아닌지 미리 확인하는 것은 또한 자신의 책임입니다 . 프로그래머가 유효성 검사를 수행하지 못하면, 그 실수를 즉시 인식해야합니다. 비정규 화 (NaN) 또는 부정확 한 (0) 계산 결과는 그 점에서 도움이되지 않습니다.

옵션 3은 가장 간단하고 정직하며 수학적으로 올바른 것으로 btw에게 추천 한 것입니다.

오류가 무시되는 환경에서 중요한 작업 (예 : "야간 크론")을 실행하는 것은 나에게 나쁜 생각 인 것 같습니다. 이것을 기능으로 만드는 것은 끔찍한 생각입니다. 이것은 옵션 1과 2를 배제합니다.

옵션 3이 유일하게 수용 가능한 솔루션입니다. 예외는 언어의 일부일 필요는 없지만 현실의 일부입니다. 종료 메시지는 오류에 대해 가능한 구체적이고 유익해야합니다.

IEEE 754는 실제로 문제에 대한 솔루션을 잘 정의했습니다. http://en.wikipedia.org/wiki/IEEE_floating_point#Exception_handling 을 사용하지 않고 예외 처리exceptions

1/0  = Inf
-1/0 = -Inf
0/0  = NaN

이런 식으로 모든 작업이 수학적으로 이해됩니다.

\ lim_ {x \ to 0} 1 / x = Inf

내 의견으로는 IEEE 754에 따르면 컴퓨터에서 계산하는 것이 정확하고 다른 프로그래밍 언어의 동작과 일치하기 때문에 계산이 가장 적합합니다.

발생하는 유일한 문제는 Inf와 NaN이 결과를 오염시키고 사용자가 문제의 원인을 정확히 알 수 없다는 것입니다. Julia와 같은 언어를 잘 살펴보십시오.

julia> 1/0
Inf

julia> -1/0
-Inf

julia> 0/0
NaN

julia> a = [1,1,1] ./ [2,1,0]
3-element Array{Float64,1}:
   0.5
   1.0
 Inf

julia> sum(a)
Inf

julia> a = [1,1,0] ./ [2,1,0]
3-element Array{Float64,1}:
   0.5
   1.0
 NaN

julia> sum(a)
NaN

나누기 오류는 수학 연산을 통해 올바르게 전파되지만 결국 사용자는 오류가 발생한 작업을 알 필요는 없습니다.

edit:Jim Pivarski의 대답의 두 번째 부분을 보지 못했습니다. 기본적으로 위에서 말한 것입니다. 내 잘못이야.

프로그래머가 아닌 사람이 가장 널리 사용하는 언어 인 SQL은 가치가있는 모든 것을 위해 # 3을 수행합니다. 프로그래머가 아닌 사람이 SQL을 작성하는 것을 관찰하고 지원하는 내 경험에서,이 동작은 일반적으로 잘 이해되고 쉽게 보상됩니다 (사례 진술 등). 예를 들어 Postgres 9에서 "오류 : 0으로 나누기"라는 오류 메시지가 매우 직접적인 경향이 있습니다.

문제는 "초보 사용자를 대상으로합니다.-> 따라서 지원이 없습니다."

초보 사용자에게 예외 처리가 문제라고 생각하는 이유는 무엇입니까?

더 나쁜 것은 무엇입니까? "어려운"기능이 있거나 왜 어떤 일이 발생했는지 모릅니다. 무엇을 더 혼란스럽게 할 수 있습니까? 코어 덤프 또는 "치명적 오류 : 0으로 나누기"와 충돌이 발생합니까?

대신, 큰 메시지 오류를 목표로하는 것이 더 좋다고 생각합니다. 대신 "잘못된 계산, 나누기 0 / 0"(즉, 문제의 종류 가 아니라 항상 문제를 일으키는 DATA를 표시하십시오 ). PostgreSql이 메시지 오류를 처리하는 방법을 살펴보십시오. 이는 훌륭한 IMHO입니다.

그러나 다음과 같은 예외를 처리하는 다른 방법을 살펴볼 수 있습니다.

http://dlang.org/exception-safe.html

나는 또한 언어를 구축하는 꿈을 가지고 있으며,이 경우 일반적인 예외와 함께 어쩌면 / 선택을 혼합하는 것이 가장 좋을 것이라고 생각합니다.

def openFile(fileName): File | Exception
    if not(File.Exist(fileName)):
        raise FileNotExist(fileName)
    else:
        return File.Open()

#This cause a exception:

theFile = openFile('not exist')

# But this, not:

theFile | err = openFile('not exist')

내 관점에서 귀하의 언어는 오류를 감지하고 처리하는 일반적인 메커니즘을 제공해야합니다. 프로그래밍 오류는 컴파일 타임에 (또는 가능한 빨리) 감지되어야하며 일반적으로 프로그램 종료로 이어져야합니다. 예기치 않은 또는 잘못된 데이터 또는 예기치 않은 외부 조건으로 인해 발생하는 오류를 감지하여 적절한 조치를 취해야하지만 가능할 때마다 프로그램을 계속 진행할 수 있도록하십시오.

그럴듯한 조치에는 (a) 종료 (b) 사용자에게 조치 프롬프트 (c) 오류 기록 (d) 수정 된 값으로 대체 (e) 코드에서 테스트 할 표시기 설정 (f) 오류 처리 루틴 호출. 이 중 어느 것이 사용 가능하고 어떤 수단으로 선택해야합니까.

내 경험상, 잘못된 변환, 0으로 나누기, 오버플로 및 범위를 벗어난 값과 같은 일반적인 데이터 오류는 양성이며 기본적으로 다른 값을 대체하고 오류 플래그를 설정하여 처리해야합니다. 이 언어를 사용하는 (비 프로그래머)는 잘못된 데이터를보고 오류를 확인하고 처리해야 할 필요성을 신속하게 이해합니다.

[예를 들어, Excel 스프레드 시트를 고려하십시오. 숫자가 넘치거나 다른 이유로 Excel에서 스프레드 시트를 종료하지 않습니다. 셀은 이상한 값을 얻습니다. 이유를 찾아서 고칩니다.]

따라서 귀하의 질문에 대답하기 위해 반드시 종료해서는 안됩니다. NaN을 대체 할 수도 있지만 계산을 완료하지 말고 계산이 완료되고 이상한 높은 값을 생성해야합니다. 그리고 필요한 사용자가 오류가 발생했음을 확인할 수 있도록 오류 플래그를 설정하십시오.

공개 : 나는 그러한 언어 구현 (Powerflex)을 만들었고 1980 년대 에이 문제 (그리고 다른 많은 것들)를 정확하게 해결했습니다. 지난 20 년 동안 프로그래머가 아닌 사람들을위한 언어는 거의 또는 전혀 발전하지 않았으며, 시도에 대한 비판을 많이받을 것입니다. 그러나 저는 여러분이 성공하기를 바랍니다.

나는 분자가 0 인 경우 대체 값을 제공하는 삼항 연산자를 좋아했습니다.

내가 보지 못한 또 하나의 아이디어는 일반적인 "유효하지 않은"값을 생성하는 것입니다. 일반적인 "이 변수는 프로그램이 나쁜 일을했기 때문에 값을 가지지 않습니다"는 자체적으로 전체 스택 추적을 수행합니다. 그런 다음 어디에서나 해당 값을 사용하면 새로운 작업을 맨 처음 시도하여 결과가 다시 유효하지 않습니다 (예 : 유효하지 않은 값이 표현식에 표시되면 전체 표현식이 유효하지 않으며 함수 호출이 시도되지 않습니다. 예외는 부울 연산자이어야 함-true 또는 invalid는 true 및 false 및 invalid는 false-다른 예외도있을 수 있습니다. 해당 값이 더 이상 어디에서나 참조되지 않으면 문제가 발생한 전체 체인에 대한 자세한 설명을 기록하고 평소처럼 비즈니스를 계속하십시오. 추적을 프로젝트 책임자에게 보내거나 이메일로 보낼 수 있습니다.

Maybe 모나드와 같은 것이 기본적으로 있습니다. 그것은 실패 할 수있는 다른 것들과 함께 작동하며 사람들이 자신의 무효를 구성하도록 허용 할 수 있습니다. 그리고 오류가 너무 심하지 않는 한 프로그램이 계속 실행될 것입니다.

0으로 나누는 데는 두 가지 근본적인 이유가 있습니다.

1. 정수와 같은 정확한 모델에서는 입력이 잘못되어 DBZ를 0으로 나눕니다. 이것은 우리 대부분이 생각하는 DBZ입니다.
2. 부동 소수점과 같은 비 정밀 모델에서는 입력이 유효하더라도 반올림 오류로 인해 DBZ가 발생할 수 있습니다. 이것이 우리가 일반적으로 생각하지 않는 것입니다.

1. 사용자는 자신이 책임이 있고 상황을 해결하는 방법을 가장 잘 알고 있기 때문에 실수를했다는 사실을 사용자에게 다시 알려야합니다.

2의 경우 이것은 사용자 결함이 아니며 알고리즘, 하드웨어 구현 등을 가리킬 수 있지만 사용자의 결함이 아니므로 프로그램을 종료하거나 예외를 던지지 않아야합니다 (이 경우 허용되지 않는 경우). 따라서 합리적인 해결책은 합리적인 방식으로 작업을 계속하는 것입니다.

이 질문을하는 사람이 사례 1을 요청한 것을 볼 수 있습니다. 따라서 사용자에게 다시 연락해야합니다. 부동 소수점 표준 인 Inf, -Inf, Nan, IEEE를 사용하면이 상황에 맞지 않습니다. 근본적으로 잘못된 전략.

언어로 금지하십시오. 즉, 일반적으로 먼저 테스트하여 0이 아닐 때까지 숫자로 나누지 마십시오. 즉.

int div = random(0,100);
int b = 10000 / div; // Error E0000: div might be zero

프로그래밍 언어를 작성할 때 사실을 활용하고 0 상태로 고안을위한 조치를 포함시켜야합니다. a <= n / c : 0 div-0-동작

방금 제안한 것은 PL에 'goto'를 추가하는 것입니다.