Beginnende programmeerboeken bevatten meestal deze waarschuwing: "Niet delen door nul! U krijgt een runtime-fout! "
Dingen zijn veranderd in VB.NET. Hoewel er meer zijn programmeren opties en de berekening is nauwkeuriger, het is niet altijd gemakkelijk om te zien waarom dingen gebeuren zoals ze gebeuren.
Hier leren we hoe om te gaan met deling door nul met behulp van VB.NET's gestructureerde foutafhandeling. En onderweg behandelen we ook de nieuwe VB.NET-constanten: NaN, Infinity en Epsilon.
Wat gebeurt er als u 'Divide By Zero' uitvoert in VB.NET
Als u een 'delen door nul'-scenario uitvoert in VB.NET, krijgt u dit resultaat:
Dim a, b, c As Double
a = 1: b = 0
c = a / b
Troosten. Schrijf lijn( _
"Heb rekenregels" _
& vbCrLf & _
"ingetrokken?" _
& vbCrLf & _
"Deling door nul " _
& vbCrLf & _
"moet mogelijk zijn!")
Wat is hier aan de hand? Het antwoord is dat VB.NET je eigenlijk het wiskundig correcte antwoord geeft. Wiskundig jij kan delen door nul, maar wat je krijgt is "oneindig".
Dim a, b, c As Double
a = 1: b = 0
c = a / b
Troosten. Schrijf lijn( _
"Het antwoord is: " _
& c)
'Wordt weergegeven:
'Het antwoord is: oneindig
De waarde "oneindig" is niet al te handig voor de meeste zakelijke toepassingen. (Tenzij de CEO zich afvraagt wat de bovengrens van zijn aandelenbonus is.) Maar het voorkomt dat uw applicaties crashen op een runtime-uitzondering zoals minder krachtige talen.
VB.NET biedt u nog meer flexibiliteit doordat u zelfs berekeningen kunt uitvoeren. Bekijk dit eens:
Dim a, b, c As Double
a = 1: b = 0
c = a / b
c = c + 1
'Infinity plus 1 is
'nog steeds oneindig
Om wiskundig correct te blijven, geeft VB.NET u het antwoord NaN (geen nummer) voor sommige berekeningen zoals 0/0.
Dim a, b, c As Double
a = 0: b = 0
c = a / b
Troosten. Schrijf lijn( _
"Het antwoord is: " _
& c)
'Wordt weergegeven:
'Het antwoord is: NaN
VB.NET kan ook het verschil zien tussen positieve oneindigheid en negatieve oneindigheid:
Dim a1, a2, b, c As Double
a1 = 1: a2 = -1: b = 0
If (a1 / b)> (a2 / b) Dan _
Troosten. Schrijf lijn( _
"Positieve oneindigheid is" _
& vbCrLf & _
"groter dan" _
& vbCrLf & _
"negatieve oneindigheid.")
Naast PositiveInfinity en NegativeInfinity biedt VB.NET ook Epsilon, de kleinste positieve dubbele waarde groter dan nul.
Houd er rekening mee dat al deze nieuwe mogelijkheden van VB.NET alleen beschikbaar zijn met floating-point (Double of Single) datatypes. En deze flexibiliteit kan leiden tot verwarring bij Try-Catch-Eindelijk (gestructureerde foutafhandeling). De .NET-code hierboven wordt bijvoorbeeld uitgevoerd zonder enige uitzondering te maken, dus het coderen in een Try-Catch-Eind-blok helpt niet. Als u wilt testen op delen door nul, moet u een test coderen zoals:
Als c. ToString = "Infinity" Dan...
Zelfs als u het programma codeert (met Integer in plaats van Single of Double types), krijgt u nog steeds een "Overflow" -uitzondering, geen "Divide by Zero" -uitzondering. Als u op internet zoekt naar andere technische hulp, zult u merken dat de voorbeelden allemaal testen op OverflowException.
.NET heeft eigenlijk DivideByZeroException als een legitiem type. Maar als de code nooit de uitzondering activeert, wanneer zie je dan ooit deze ongrijpbare fout?
Wanneer u DivideByZeroException ziet
Zoals het blijkt, Microsoft's MSDN-pagina over Try-Catch-Eindblokken gebruikt eigenlijk een delen door nul voorbeelden om te illustreren hoe ze te coderen. Maar er is een subtiele "vangst" die ze niet verklaren. Hun code ziet er zo uit:
Dim a As Geheel getal = 0
Dim b als geheel getal = 0
Dim c als geheel getal = 0
Proberen
a = b \ c
Vang exc als uitzondering
Troosten. WriteLine ("Er is een runtime-fout opgetreden")
Tenslotte
Troosten. Lees regel()
Einde proberen
Deze code doet een daadwerkelijke verdeelactie door nul activeren.
Maar waarom veroorzaakt deze code de uitzondering en niets dat we eerder hebben gecodeerd? En wat verklaart Microsoft niet?
Merk op dat de operatie die ze gebruiken is niet divide ("/"), het is integer divide ("\")! (Andere Microsoft-voorbeelden verklaren de variabelen eigenlijk als Geheel getal.) Het blijkt dat de berekening van het geheel getal de is enkel en alleen geval dat eigenlijk die uitzondering veroorzaakt. Het zou leuk geweest zijn als Microsoft (en de andere pagina's die hun code kopiëren) dat kleine detail zouden verklaren.