Is divide by zero an error or an exception?

Like anything else - you either test it or read the documentation. It can be an "Error" or an "Exception" based on the language Eg C: Crashes and gives a divide by zero error Ruby: 6 / 0 ZeroDivisionError: divided by 0 from (irb):1:in `/' from (irb):1 (ZeroDivisionError is actually an exception. ) Java: Code: int x = 6 / 0 Output: Exception in thread "main" java.lang.

ArithmeticException: / by zero.

Like anything else - you either test it or read the documentation. It can be an "Error" or an "Exception" based on the language. Eg.

C: Crashes and gives a divide by zero error. Ruby: >> 6 / 0 ZeroDivisionError: divided by 0 from (irb):1:in `/' from (irb):1 (ZeroDivisionError is actually an exception. ) Java: Code: int x = 6 / 0; Output: Exception in thread "main" java.lang.

ArithmeticException: / by zero.

ZeroDivisionError is an exception – Joel Lee Mar 25 at 18:28 Ah you're right. I updated it, using the obvious C as one that errors. – AndrewKS Mar 25 at 18:33 +1 for "the only way to know is to test it or read the documentation".

– Joel Lee Mar 25 at 18:46.

It depends on the language : some languages don't have exceptions some languages don't use exceptions for everything. For example, in PHP : There are exceptions But divide by 0 doesn't cause an exception to be thrown : is only raises a warning -- that doesn't stop the execution of the script. The following portion of code : echo 10 / 0; echo "hello, world!"; Would give this result : Warning: Division by zero in /.../temp.

Php on line 5 hello, world!

The terms error and exception are commonly used as jargon terms, with meanings that vary depending upon the programming ecosystem in which they are used. Conditions This response follows the lead of Common Lisp, and adopts the term condition as a nonjudgmental way of referring to an "interesting situation" in a program. What makes a program condition "interesting"?

Let's consider the division-by-zero case for real numbers. In the overwhelming majority of cases in which one real is divided by another, the result is another plain ordinary well-behaved real number. These are the "routine" or "uninteresting" cases.

However, in the case that the divisor is zero then, mathematically speaking, the result is undefined. The program is now in an "interesting" or "exceptional" condition. It becomes even more complicated once we take the mathematical ideal of a real number and model it, say, as an IEEE-format floating point number.

If we divide 1.0 / 0.0, the IEEE standard (mostly) says that the result is in fact another floating point number, the quiet NaN Infinity. Since the result no longer behaves in the same way as a plain old real number, the program condition is once again "interesting" or "exceptional". Classifying Conditions The question is: what should we do when we run into an interesting condition?

The answer is dependent upon the context. When classifying program conditions, the following questions are useful: How likely is it that the condition will occur: certain, probable, unlikely, impossible? How is the condition detected: program malfunction, distinguished value, signal/handler (aka exception handling), program termination?

How should the condition be handled: ignore it, perform some special action, terminate the program? The answers to these questions yield 4 x 4 x 3 = 48 distinct cases -- and surely more could be distinguished by further criteria. This brings us to the heart of the matter.

We have more than two cases but only two labels, error and exception, to apply to them. Needless to say, there are many possible ways to divide the 48+ cases into two groups. For example, one could say that anything involving program malfunction is an error, anything else is an exception.

Or that anything involving a language's built-in exception handling facilities is an exception, anything else is an error. The possibilities are legion. Examples End-Of-File When reading and processing a stream of characters, hitting the end-of-file is certain.In C, this event is detected by means of a distinguished return value from an I/O function, a so-called error return value.

Thus, one speaks of an EOF error. Division-By-Zero When dividing two user-entered numbers in a simple calculator program, we want to give a meaningful result even if the user enters a divisor of zero.In some C environments, division-by-zero results in a signal (SIGFPE) that must be fielded by a signal handler. Signals are sometimes called exceptions in the C community and, confusingly, sometimes called program error signals.

In other C environments, IEEE floating-point rules apply and the division-by-zero would result in a NaN value. The C environment would be blissfully unaware of that value, considering it to be neither an exception nor an error. Runtime Load Failure Programs frequently load their program code dynamically at run-time (e.g. Classes, DLLs).

This might fail due to a missing file. C offers no standard way to detect or recover from this case. The program would be terminated involuntarily, and one often speaks of this situation as a fatal exception.In Java, this would be termed a linkage error.

Java's Throwable erarchy Java's exception-handling system divides the so-called Throwable class hierarchy into two main groups. Subclasses of Error are meant to represent conditions from which recovery is impossible. Subclasses of Exception are meant for recoverable conditions are are further subdivided into checked exceptions (for probable conditions) and unchecked exceptions (for unlikely conditions).

Unfortunately, the boundaries between these categories are poorly defined and you will often find instances of throwables whose semantics suggest that they belong in a different category. Be Wary Of Jargon These examples show that the meanings of error and exception are murky at best. One must treat error and exception as jargon, whose meaning is determined by the context of discussion.

Of greater value are distinguishing characteristics of program conditions. What is the likelihood of the condition occurring? How is the condition detected?

What action should be taken when the condition is detected? In any discussion that demands clarity, one is better suited to answer these questions directly rather than relying upon jargon terminology.

Looking at Java, I can "recover" from an exception. I, as a program, can still survive if the file I want to read doesn't exist and tell this nicely and ask for a actual file. But in some other language, say plain vanilla C, I die if I try to read a non existent file.

Of course I can check if the file exists but when I try to access a non existent file w/out checking its existence will be frowned upon. I have an opinion that errors are not exceptions and both are different. After reading your warning, I think I may have to change my opinion.

– Kumar Mar 26 at 19:41 I never had a chance to work in Java or . NET, mingled with C and C++ but am more of a web developer :) – Kumar Mar 26 at 19:44.

Exceptions should indicate exceptional activity, so if you reach a point in your code for which you've done your best to avoid divide by zero, then throwing an exception (if you are able to in your language) is the right way. If it's routine logic to check for divide by zero (like for a calculator app) then you should check for that in your code before it has the chance to raise an exception. In that case, it's an error (in user input) and should be handled as such.(Stole this idea either from The Pragmatic Programmer or Code Complete; can't remember which.).

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.