NaN, oneindig en delen door nul in VB.NET
Beginnende programmeerboeken bevatten meestal deze waarschuwing: 'Niet delen door nul! U krijgt een runtime-fout!'
Er zijn dingen veranderd in VB.NET . Hoewel er meer zijn programmeren opties en de berekening nauwkeuriger is, is het niet altijd gemakkelijk om te zien waarom de dingen gebeuren zoals ze gebeuren.
Hier leren we hoe we delen door nul kunnen verwerken met behulp van de gestructureerde foutafhandeling van VB.NET. En onderweg behandelen we ook de nieuwe VB.NET-constanten: NaN, Infinity en Epsilon.
Wat gebeurt er als u 'Delen door nul' uitvoert in VB.NET
Als je een 'verdeel door nul'-scenario uitvoert in VB.NET, krijg je dit resultaat:
|_+_||_+_||__+_|
|__+_|
|__+_|
|__+_|
|__+_|
|__+_|
|__+_|
|__+_|
|__+_|
|__+_|
Dus wat is hier aan de hand? Het antwoord is dat VB.NET je eigenlijk het wiskundig correcte antwoord geeft. Wiskundig gezien, jij kan delen door nul, maar wat je krijgt is 'oneindig'.
|_+_||_+_|
|__+_|
|__+_|
|__+_|
|__+_|
|__+_|
|__+_|
|__+_|
De waarde 'oneindig' is niet zo handig voor de meeste zakelijke toepassingen. (Tenzij de CEO zich afvraagt wat de bovengrens van zijn aandelenbonus is.) Maar het zorgt er wel voor dat uw applicaties niet crashen op een runtime-uitzondering, zoals minder krachtige talen doen.
VB.NET geeft u nog meer flexibiliteit doordat u zelfs berekeningen kunt uitvoeren. Bekijk dit eens:
|_+_||_+_||__+_|
|__+_|
|__+_|
|__+_|
|__+_|
Om wiskundig correct te blijven, geeft VB.NET je het antwoord NaN (Not a Number) voor sommige berekeningen zoals 0 / 0.
|_+_||_+_||__+_|
|__+_|
|__+_|
|__+_|
|__+_|
|__+_|
|__+_|
VB.NET kan ook het verschil zien tussen positieve oneindigheid en negatieve oneindigheid:
|_+_||_+_|
|__+_|
|__+_|
|__+_|
|__+_|
|__+_|
|__+_|
|__+_|
|__+_|
Naast PositiveInfinity en NegativeInfinity biedt VB.NET ook Epsilon, de kleinste positieve Double-waarde groter dan nul.
Houd er rekening mee dat al deze nieuwe mogelijkheden van VB.NET alleen beschikbaar zijn met gegevenstypen met drijvende komma (dubbel of enkel). En deze flexibiliteit kan leiden tot enige Try-Catch-Finally (gestructureerde foutafhandeling) verwarring. De bovenstaande .NET-code wordt bijvoorbeeld uitgevoerd zonder enige uitzondering te maken, dus het zal niet helpen om deze in een Try-Catch-Finally-blok te coderen. Om te testen op een deel door nul, zou je een test moeten coderen als:
|_+_||_+_|
Zelfs als u het programma codeert (met Integer in plaats van Single of Double-types), krijgt u nog steeds een 'Overflow' Exception, niet een 'Devide 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 de DivideByZeroException als een legitiem type. Maar als de code nooit de uitzondering activeert, wanneer ziet u dan ooit deze ongrijpbare fout?
Wanneer u DivideByZeroException ziet
Zoals het blijkt, Microsoft 's MSDN-pagina over Try-Catch-Finally-blokken gebruikt in feite voorbeelden van delen door nul om te illustreren hoe ze moeten worden gecodeerd. Maar er is een subtiele 'catch' die ze niet uitleggen. Hun code ziet er als volgt uit:
|_+_||_+_||__+_|
|__+_|
|__+_|
|__+_|
|__+_|
|__+_|
|__+_|
|__+_|
|__+_|
|__+_|
Deze code doet een daadwerkelijke deling door nul-uitzondering activeren.
Maar waarom activeert deze code de uitzondering en niets wat we eerder hebben gecodeerd? En wat legt Microsoft niet uit?
Merk op dat de bewerking die ze gebruiken is: niet delen ('/'), het is geheel getal delen ('')! (Andere Microsoft-voorbeelden declareren de variabelen eigenlijk als geheel getal.) Het blijkt dat de berekening van gehele getallen de enkel en alleen geval dat daadwerkelijk die uitzondering genereert. Het zou leuk geweest zijn als Microsoft (en de andere pagina's die hun code kopiëren) dat kleine detail hadden uitgelegd.