În general, cărțile de programare includ acest avertisment: „Nu împărțiți la zero! Veți primi o eroare de execuție! "
Lucrurile s-au schimbat VB.NET. Deși sunt mai multe programare opțiuni, iar calculul este mai precis, nu este întotdeauna ușor să vezi de ce se întâmplă lucrurile așa cum fac.
Aici, învățăm cum să gestionăm diviziunea la zero folosind manipularea structurată a erorilor VB.NET. Și pe parcurs, acoperim și noile constante VB.NET: NaN, Infinity și Epsilon.
Ce se întâmplă dacă executați „Divide By Zero” în VB.NET
Dacă executați un scenariu „împărțiți la zero” în VB.NET, obțineți acest rezultat:
Dim a, b, c Ca dublă
a = 1: b = 0
c = a / b
Consolă. WriteLine (_
"Au reguli matematice" _
& vbCrLf & _
"a fost abrogat?" _
& vbCrLf & _
"Impartirea cu zero " _
& vbCrLf & _
„trebuie să fie posibil!”)
Deci, ce se întâmplă aici? Răspunsul este că VB.NET vă oferă de fapt răspunsul corect din punct de vedere matematic. Matematic, tu poate sa împărțiți la zero, dar ceea ce obțineți este „infinitul”.
Dim a, b, c Ca dublă
a = 1: b = 0
c = a / b
Consolă. WriteLine (_
"Raspunsul este: " _
& c)
Afișează:
„Răspunsul este: infinitul
Valoarea „infinit” nu este prea utilă pentru majoritatea aplicațiilor de afaceri. (Cu excepția cazului în care CEO-ul se întreabă care este limita superioară a bonusului său de acțiuni.) Dar aceasta împiedică aplicațiile dvs. să se prăbușească pe o excepție de rulare, cum ar fi limbile mai puțin puternice.
VB.NET vă oferă și mai multă flexibilitate, permițându-vă chiar să efectuați calcule. Verificați acest lucru:
Dim a, b, c Ca dublă
a = 1: b = 0
c = a / b
c = c + 1
„Infinity plus 1 is
'încă la infinit
Pentru a rămâne corect din punct de vedere matematic, VB.NET vă oferă răspunsul NaN (Nu un număr) pentru unele calcule, cum ar fi 0/0.
Dim a, b, c Ca dublă
a = 0: b = 0
c = a / b
Consolă. WriteLine (_
"Raspunsul este: " _
& c)
Afișează:
„Răspunsul este: NaN
VB.NET poate spune, de asemenea, diferența dintre infinitul pozitiv și infinitul negativ:
Dim a1, a2, b, c Ca dublă
a1 = 1: a2 = -1: b = 0
Dacă (a1 / b)> (a2 / b) Atunci _
Consolă. WriteLine (_
"Infinitul postiv este" _
& vbCrLf & _
"mai mare ca" _
& vbCrLf & _
"infinit negativ.")
În plus față de PositiveInfinity și NegativeInfinity, VB.NET oferă și Epsilon, cea mai mică valoare dublă pozitivă mai mare decât zero.
Rețineți că toate aceste noi capabilități ale VB.NET sunt disponibile numai cu tipuri de date cu punct flotant (dublu sau unic). Și această flexibilitate poate duce la o confuzie cu Try-Catch-Final (manipularea erorilor structurate). De exemplu, codul .NET de mai sus rulează fără a arunca niciun fel de excepție, astfel încât codificarea acestuia într-un bloc Try-Catch-Final nu va ajuta. Pentru a testa o împărțire cu zero, ar trebui să codați un test de genul:
Dacă c. ToString = "Infinity" Atunci...
Chiar dacă codificați programul (utilizând Integer în loc de tipuri Single sau Double), primiți în continuare o excepție „Overflow”, nu o excepție „Divide by Zero”. Dacă căutați pe web un alt ajutor tehnic, veți observa că toate exemplele testează OverflowException.
.NET are de fapt DivideByZeroException ca un tip legitim. Dar dacă codul nu declanșează niciodată excepția, când veți vedea vreodată această eroare evazivă?
Când veți vedea DivideByZeroException
După cum se dovedește, MicrosoftPagina MSDN despre blocurile Try-Catch-Final folosește de fapt exemple de împărțire la zero pentru a ilustra modul de codare a acestora. Dar există o „captură” subtilă pe care ei nu o explică. Codul lor arată astfel:
Dim a As Integer = 0
Dim b Ca număr întreg = 0
Dim c Ca număr întreg = 0
Încerca
a = b \ c
Catch exc ca excepție
Consolă. WriteLine ("A apărut o eroare în timpul executării")
In cele din urma
Consolă. Citeste linia()
Încearcă
Acest cod face declanșează o divizare reală cu zero excepție.
Dar de ce acest cod declanșează excepția și nimic din ce am codat înainte? Și ce nu explică Microsoft?
Observați că operația pe care o folosesc este nu divide ("/"), este divizare întreagă ("\")! (Alte exemple Microsoft declară de fapt variabilele ca fiind întregi.) După cum se dovedește, calculul întreg este numai caz care aruncă de fapt această excepție. Ar fi fost frumos dacă Microsoft (și celelalte pagini care își copiază codul) ar fi explicat acele mici detalii.