I libri di programmazione di inizio di solito includono questo avviso: "Non dividere per zero! Riceverai un errore di runtime! "
Le cose sono cambiate in VB.NET. Anche se ce ne sono altri programmazione opzioni e il calcolo è più accurato, non è sempre facile capire perché le cose accadano nel modo in cui si svolgono.
Qui, impariamo come gestire la divisione per zero utilizzando la gestione strutturata degli errori di VB.NET. E lungo il percorso, copriamo anche le nuove costanti VB.NET: NaN, Infinity ed Epsilon.
Cosa succede se si esegue "Dividi per zero" in VB.NET
Se si esegue uno scenario 'dividi per zero' in VB.NET, si ottiene questo risultato:
Dim a, b, c Come doppio
a = 1: b = 0
c = a / b
Console. Linea di scrittura( _
"Avere regole matematiche" _
& vbCrLf & _
"abrogato?" _
& vbCrLf & _
"Divisione per zero " _
& vbCrLf & _
"deve essere possibile!")
Quindi cosa sta succedendo qui? La risposta è che VB.NET ti dà effettivamente la risposta matematicamente corretta. Matematicamente, tu può dividi per zero, ma quello che ottieni è "infinito".
Dim a, b, c Come doppio
a = 1: b = 0
c = a / b
Console. Linea di scrittura( _
"La risposta è: " _
e c)
'Visualizza:
'La risposta è: infinito
Il valore "infinito" non è troppo utile per la maggior parte delle applicazioni aziendali. (A meno che il CEO non si stia chiedendo quale sia il limite massimo del suo bonus azionario.) Ma impedisce alle applicazioni di arrestarsi in modo anomalo su un'eccezione di runtime come fanno le lingue meno potenti.
VB.NET ti offre una flessibilità ancora maggiore, consentendoti persino di eseguire calcoli. Controllalo:
Dim a, b, c Come doppio
a = 1: b = 0
c = a / b
c = c + 1
'Infinity plus 1 è
'ancora infinito
Per rimanere matematicamente corretto, VB.NET ti dà la risposta NaN (Not a Number) per alcuni calcoli come 0/0.
Dim a, b, c Come doppio
a = 0: b = 0
c = a / b
Console. Linea di scrittura( _
"La risposta è: " _
e c)
'Visualizza:
'La risposta è: NaN
VB.NET può anche dire la differenza tra infinito positivo e infinito negativo:
Dim a1, a2, b, c Come doppio
a1 = 1: a2 = -1: b = 0
Se (a1 / b)> (a2 / b) Quindi _
Console. Linea di scrittura( _
"L'infinito postivo è" _
& vbCrLf & _
"più grande di" _
& vbCrLf & _
"infinito negativo")
Oltre a PositiveInfinity e NegativeInfinity, VB.NET fornisce anche Epsilon, il valore Double positivo più piccolo maggiore di zero.
Tenere presente che tutte queste nuove funzionalità di VB.NET sono disponibili solo con tipi di dati a virgola mobile (doppio o singolo). E questa flessibilità può generare confusione Try-Catch-Infine (gestione degli errori strutturati). Ad esempio, il codice .NET sopra riportato viene eseguito senza generare alcun tipo di eccezione, pertanto la codifica all'interno di un blocco Try-Catch-Infine non aiuta. Per testare una divisione per zero, dovresti codificare un test come:
Se c. ToString = "Infinity" Quindi...
Anche se si codifica il programma (utilizzando Integer anziché i tipi Single o Double), si ottiene comunque un'eccezione "Overflow", non un'eccezione "Divide by Zero". Se cerchi sul web altri aiuti tecnici, noterai che tutti gli esempi testano OverflowException.
.NET in realtà ha DivideByZeroException come tipo legittimo. Ma se il codice non attiva mai l'eccezione, quando vedrai mai questo errore inafferrabile?
Quando vedrai DivideByZeroException
Come risulta, MicrosoftLa pagina MSDN sui blocchi Try-Catch-Infine utilizza effettivamente una divisione per zero esempi per illustrare come codificarli. Ma c'è una sottile "cattura" che non spiegano. Il loro codice è simile al seguente:
Dim a As Intero = 0
Dim b come intero = 0
Dim c come numero intero = 0
Provare
a = b \ c
Cattura ecc. Come eccezione
Console. WriteLine ("Si è verificato un errore di runtime")
Infine
Console. Linea di lettura()
End Try
Questo codice fa attivare una divisione effettiva per zero eccezione.
Ma perché questo codice attiva l'eccezione e nulla di ciò che abbiamo codificato prima? E cosa non sta spiegando Microsoft?
Si noti che l'operazione che utilizzano è non divide ("/"), è intero divide ("\")! (Altri esempi di Microsoft dichiarano effettivamente le variabili come Integer.) A quanto pare, il calcolo dei numeri interi è il solo caso che effettivamente genera tale eccezione. Sarebbe stato bello se Microsoft (e le altre pagine che copiano il loro codice) spiegassero quel piccolo dettaglio.