Olisko mahdollista saada vb erroreita pois ilman että etsii jokaisen virheen ja korjaa.
esim jos shell komento ei löydä tiedostoa niin koko exe kaatuu.
No heti uutta ominaisuutta ohjelmaasi koodatessa, tee siihen samalla virheentarkistus, että ei kaaduta jos jokin menee pieleen. Tuohon voisin sanoa, että tutki ensin Dir-komennolla, onko se tiedosto varmasti siellä, mistä sitä haetaan. Tutki putkan Vb/tiedostot ja hakemistot koodivinkkejä. SIellä on juuri tuosta tiedoston olemassaolon tarkastamisesta.
MUOK: Laitan nyt tähän samaan sittenkin:
If Dir("tiedoston_polku_ja_nimi") <> "" then MsgBox "Tiedosto on" Else MsgBox "Eipäs onnistu" End If
TUPLA MUOK: Voithan käyttää
On Error Resume Next
komentoa, mutta sen käyttöä en osaa neuvoa, kun en itse ole käyttänyt.
Mä lähinnä käytin tota tiedosto avausta esimerkkinä, oikeesti mä teen winsockilla ja connection erroreita tulee tuhansia vaikka puolet oon jo yrittäny fixata.
Kiitos toi on error resume next toimi :]
se pitää laittaa ominaisuuden yläpuolelle..
En suosittele tuon On Error Resume Next käyttöä koska ohjelmasi kaatuessa kaatuu usein koko kone mukana.
Eli ihan kunnon virheenkäsittely kehiin:
On Error Goto Errh 'koodia... Errh: if Err.Number = ja_virhe_numero_tähän Then 'mitä tehdään kyseisen virheen sattuessa. End if
Minä en suosittele On Error -ominaisuuden käyttöä muutenkaan, jos käytön syy on vain se, ettei jaksa etsiä ohjelmansa bugeja. Bugit pitää ehdottomasti yrittää ensin poistaa, ja virheenkäsittelyrutiinin voi pistää ohjelmaan siltä varalta, että mukana on mahdollisesti bugeja, joihin ei ole koodatessa sattunut törmäämään, tai sitten, jos nimenomaan tietää, mitä virheitä voi sattua, ja haluaa määrittää niille jonkin tietyn seurauksen.
Ja ennen tuota Errh: -labelia vielä toki Exit [Sub|Function|Property], jotta tuota virheenkäsittelykoodia ei suoriteta silloinkin, kun mitään virhettä ei ole :)
Tuo Resume Next-komento on sellainen mitä ei olisi koko kieleen pitänyt lisätä.
Tuolla tavalla saat koodiisi käsittämättömiä bugeja, joita on mahdoton testata ja korjata, koska et huomaa niitä ja ohjelma jatkaa virheestä huolimatta.
Tuo tuomaksen tapa on VB:ssä oikea tapa tapauskohtaisia testauksia lukuunottamatta...
Eihän tuo haittaa jos bugit on esim.: "Wrong connection state"
Resume/Resume Next:stä ei ehkä ole suoraan haittaa, mutta se on huonoa ohjelmointia, jota tulisi välttää joka tapauksessa.
Itse taas olen sitä mieltä, että On Erroria tulisi käyttää aina kun on vähänkään laajempi ohjelma kyseessä. Silloin virheen sattuessa poistuminen ohjelmasta on hallittua, eikä esim. tietokantayhteydet jää auki, kun ohjelmasta lentää holtittomasti ulos. Itse käytän virhetarkistuksessa seuraavaa rakennetta.
Private Sub Esimerkki() Dim i As Integer On Error Goto ErrorTerror MsgBox "Tämä on esimerkki. Seuraavassa sattuu virhe," & _ vbCrLf & "josta annetaan käyttäjälle virheilmoitus.", _ vbInformation, "Esimerkki" i = "Eihän tämä tuohon mene" Exit Sub ErrorTerror: If Err.Number <> 0 Then MsgBox Err.Number & ": " & Err.Description, vbCritical, "Esimerkki" 'virheilmon otsikkona siis sen [Sub|Function|Property]:n nimi missä ollaan Err.Clear End If Exit Sub
Tietää siis suurinpiirtein jo virheilmosta mikä virhe ja missä se sattuu, eli minne asettaa Breakpointia, jos virhe ei paljastu muuten kuin koodia ajamalla.
Edit: Tyop, Toyp, Typo...
Ite ajattelin kanssa ohjata sen omaan virheilmotukseen ja siitä laittaa vaikka sillee että se lähettää sen samalla tyylillä kun windowssin virheilmotus niin ite näkee jos ohjelmassa tulee jollakin virheitä...
Ja siis tottakai on hyvä että errorit tulee esille, mutta ei vaan ole kauhean hyvä jos koko ohjelma kaatuu siihen...
Aihe on jo aika vanha, joten et voi enää vastata siihen.