We are searching data for your request:

**Forums and discussions:**

**Manuals and reference books:**

**Data from registers:**

**Wait the end of the search in all databases.**

Upon completion, a link will appear to access the found materials.

Upon completion, a link will appear to access the found materials.

Beginning programming books usually include this warning: "Don't divide by zero! You'll get a runtime error!"

Things have changed in VB.NET. Although there are more programming options and the calculation is more accurate, it isn't always easy to see why things happen the way they do.

Here, we learn how to handle division by zero using VB.NET's structured error handling. And along the way, we also cover the new VB.NET constants: NaN, Infinity, and Epsilon.

### What Happens If You Run 'Divide By Zero' in VB.NET

If you run a 'divide by zero' scenario in VB.NET, you get this result:

Dim a, b, c As Double

a = 1 : b = 0

c = a / b

Console.WriteLine( _

"Have math rules" _

& vbCrLf & _

"been repealed?" _

& vbCrLf & _

"Division by zero " _

& vbCrLf & _

"must be possible!")

So what's going on here? The answer is that VB.NET actually gives you the mathematically correct answer. Mathematically, you *can* divide by zero, but what you get is "infinity".

Dim a, b, c As Double

a = 1 : b = 0

c = a / b

Console.WriteLine( _

"The answer is: " _

& c)

' Displays:

' The answer is: infinity

The value "infinity" isn't too useful for most business applications. (Unless the CEO is wondering what the upper limit on his stock bonus is.) But it does keep your applications from crashing on a runtime exception like less powerful languages do.

VB.NET gives you even more flexibility by even allowing you to perform calculations. Check this out:

Dim a, b, c As Double

a = 1 : b = 0

c = a / b

c = c + 1

' Infinity plus 1 is

' still infinity

To remain mathematically correct, VB.NET gives you the answer NaN (Not a Number) for some calculations such as 0 / 0.

Dim a, b, c As Double

a = 0 : b = 0

c = a / b

Console.WriteLine( _

"The answer is: " _

& c)

' Displays:

' The answer is: NaN

VB.NET can also tell the difference between positive infinity and negative infinity:

Dim a1, a2, b, c As Double

a1 = 1 : a2 = -1 : b = 0

If (a1 / b) > (a2 / b) Then _

Console.WriteLine( _

"Postive infinity is" _

& vbCrLf & _

"greater than" _

& vbCrLf & _

"negative infinity.")

In addition to PositiveInfinity and NegativeInfinity, VB.NET also provides Epsilon, the smallest positive Double value greater than zero.

Keep in mind that all of these new capabilities of VB.NET are only available with floating point (Double or Single) data types. And this flexibility can lead to some Try-Catch-Finally (structured error handling) confusion. For example, the .NET code above runs without throwing any kind of exception, so coding it inside a Try-Catch-Finally block won't help. To test for a divide by zero, you would have to code a test something like:

If c.ToString = "Infinity" Then…

Even if you code the program (using Integer instead of Single or Double types), you still get an "Overflow" Exception, not a "Divide by Zero" exception. If you search the web for other technical help, you will notice that the examples all test for OverflowException.

.NET actually has the DivideByZeroException as a legitimate type. But if the code never triggers the exception, when will you ever see this elusive error?

### When You'll See DivideByZeroException

As it turns out, Microsoft's MSDN page about Try-Catch-Finally blocks actually uses a divide by zero examples to illustrate how to code them. But there's a subtle "catch" that they don't explain. Their code looks like this:

Dim a As Integer = 0

Dim b As Integer = 0

Dim c As Integer = 0

Try

a = b c

Catch exc As Exception

Console.WriteLine("A run-time error occurred")

Finally

Console.ReadLine()

End Try

This code *does* trigger an actual divide by zero exception.

But why does this code trigger the exception and nothing we've coded before does? And what is Microsoft not explaining?

Notice that the operation they use is *not* divide ("/"), it's integer divide ("")! (Other Microsoft examples actually declare the variables as Integer.) As it turns out, integer calculation is the *only* case that actually throws that exception. It would have been nice if Microsoft (and the other pages that copy their code) explained that little detail.