'Try-Catch' kivetélkezelés VB, VBA, VBScript-ben
2009-10-28T11:08:00+01:00
2009-10-30T17:41:01+01:00
2022-07-25T09:36:17+02:00
  • "Én csak megmutattam, hogy több utasítás esetén nem használható."
    Rendben, igazad van és ezt meg is köszönöm, mert ez tényleg nem volt egyértelmű eddig.
    Mutasd a teljes hozzászólást!
  • "Persze, mert rosszul használod a "Try" blokkot."
    Én csak megmutattam, hogy több utasítás esetén nem használható.

    Mutasd a teljes hozzászólást!
  • Aki ki akarja próbálni, nem kell feltétlenül feltelepítenie egy régi Visual Basic-et.
    A weboldalamról letölthető példák között van egy Excel fájl is, benne egyszerű példa programokkal, amik teljesen egyen értékűek VB6-tal.
    Ha pedig az Add-Int akarja valaki kipróbálni, ahhoz csak 1 batch fájlt kell lefuttatnia és máris használható az üres blokkok és egyéb hasznos dolgok "intelligens" beszúrása a forráskódba.
    Mutasd a teljes hozzászólást!
  • Ha bebizonyítod tiéd a láda sör.
    Mutasd a teljes hozzászólást!
  • Továbbra is tartom magam a véleményemhez: nagyon nem újdonság a VB hibakezelésében
    Mutasd a teljes hozzászólást!
  • A Try-Catch utasításban lehet használni több utasítást is a hibatesztelő szakaszban.
    A "Try" blokk tesztelő szakaszában nem szabad több utasítást használni, mert hibás programhoz vezethet.
    Ettől függetlenül nagyon jól és korrekt módon használható az előre VÁRT hibák elkapásához, hasonlóan a beépített Try-Catch utasításokhoz.
    Ez az, ami újdonság a hibakezelés területén a VB-ben.

    Mutasd a teljes hozzászólást!
  • Mert ő valóban try blokként próbálja használni, miközben arról szó sincs.
    Mutasd a teljes hozzászólást!
  • "Olyan mintha nem is történt volna hiba."
    Persze, mert rosszul használod a "Try" blokkot.

    Az előbbi hozzászólásomban két példával is leírtam, hogy hogyan kéne megoldani a "problémádat".
    Mutasd a teljes hozzászólást!
  • With New Try: On Error Resume Next nTest = 1 / 0 'ITT Történt egy hiba Call Inc(nTest) 'Ez az eljárás kinullázza az Err-t. .Catch: On Error GoTo 0: Select Case .Number Case 11 MsgBox .Description 'Igy ez már meg sem történik End Select: End With
    Olyan mintha nem is történt volna hiba.


    Mutasd a teljes hozzászólást!
  • Itt a megoldás a példádra:
    Option Explicit Public Sub Inc(ByRef x As Variant) On Error GoTo labFail x = x + 1 Exit Sub labFail: End Sub Public Sub Test() Dim nTest With New Try: On Error Resume Next nTest = 1 / 0 'Division by zero! .Catch: On Error GoTo 0: Select Case .Number Case 11 MsgBox .Description End Select: End With Inc(nTest) End Sub

    Az 'Inc(nTest)'-et a "Try" blokk után kell meghívni.
    Felesleges amúgy is ellenőrizni, hogy hibázik-e az Inc, mert az Inc eljárás eleve hiba ellenőrzött eljárás, tehát nem okozhat hibát a meghívása. Ha pedig az volt a cél, hogy az 'Inc(nTest)' eljárásod NE hajtódjon végre, ha hiba történik, a "Try" blokk tesztelési szakaszában, azt valóban másképp kell szervezni, mint a Try-Catch utasításnál:
    Public Sub Test() Dim nTest With New Try: On Error Resume Next nTest = 1 / 0 'Division by zero! .Catch: On Error GoTo 0: Select Case .Number Case 11 MsgBox .Description Case 0 Inc(nTest) End Select: End With End Sub
    Az 'Inc(nTest)' itt csak akkor fog lefutni, ha nem történik hiba, azaz nincs nullával való osztás.
    (A Call utasítást felesleges használni, de ez a te dolgod, nem szólok bele.)

    Még nem írtam, de gondolom, aki jobban megnézte, annak eddig is nyilvánvaló volt, hogy csak 1 db ELŐRE VÁRT hiba elkapásához való a "Try" blokk.
    Ha több ELŐRE VÁRT hibát akar valaki elkapni, ahhoz több "Try" blokkot kell felvenni a kódba, de ez a Try-Cath utasításnál is így van általában.
    Ha pedig NEM VÁRT hibákat (főleg programozási hibákat vagy le nem kezelt objektum hibákat, ...) akar valaki elkapni, arra ott van továbbra is a VB régi, jól bevált eljárás szintű error csapdája 'On Error GoTo ...'-val az eljárás elején.
    A "Try" blokk sok mindenben hasonlít a Try-Catch utasításra, de természetesen nem ugyanaz.
    A "Try" blokk arra használható nagyon jól, hogy elkapjunk 1 db ELŐRE VÁRT hibát és e tekintetben összehasonlítható a Try-Catch utasítással.
    Ennek fényében a Try blokkok egymásba ágyazhatók gond nélkül.
    Legfeljebb akkor kell észnél lenni, ha már van egy eljárás szintű error csapda, és ehhez szeretnénk igazítani a "Try" blokk 'On Error Goto ...' utasítását is.
    Erre viszont ott van az az Add-In, amiről már említést tettem, és ami nagyon megkönnyíti és meggyorsítja az ilyen szituációk kezelését.
    Mutasd a teljes hozzászólást!
  • "A Try blokkok egymásba ágyazhatók különösebb megkötések nélkül."
    Ez is csak abban az esetben lehetne igaz ha elfogadnánk, hogy csak az utolsó hiba derül ki.
    Mutasd a teljes hozzászólást!

  • "A With blokk melyik részére gondolsz?"
    Option Explicit Public Sub Inc(ByRef x As Variant) On Error GoTo labFail x = x + 1 Exit Sub labFail: End Sub Public Sub Test() Dim nTest With New Try: On Error Resume Next nTest = 1 / 0 'Division by zero! Call Inc(nTest) .Catch: On Error GoTo 0: Select Case .Number Case 11 MsgBox .Description End Select: End With End Sub
    Mutasd a teljes hozzászólást!
  • De, ki fog

    Ezzel abszolút nincs semmi probléma.
    Mutasd a teljes hozzászólást!
  • Bocs, nem vagyok egy nagy fórumozó.
    Sajnos még így is maradt még benne egy hiba, de, megígérem, hogy ezentúl közvetlenül, itt nem fogom szerkeszteni a hozzászólásaimat.
    Mutasd a teljes hozzászólást!

  • Mielőtt elküldenéd a hozzászólást, nézd át. 23-szor szerkeszteni, már kicsit túlzás. Le fogom zárni a topicot, ha még egy hozzászólást 3-nál több alkalommal szerkesztesz egy szó miatt...
    Mutasd a teljes hozzászólást!
  • ""On Error Resume Next" miatt csak az utolsó hiba derül ki."
    1. Ha eljárás szintű error csapdát akarsz állítani, ahol el akarod kapni a nem várt hibákat (amik főleg a programozási hibákból erednek), ahhoz használd továbbra is az 'On Error Goto ...'-t, az eljárás elején, ahogyan az eddig is szokás volt a VB-ben.
    2. Ha olyan errort akarsz elkapni, amire előre számítasz, ott használd az én "Try" blokkomat.
    3. Amire te akarsz célozni, gondolom az, az, hogy egyszerre mindkét féle hibát elkapni és lekezelni.
    Én ennek nem sok előnyét látom és nem is javaslom, mert kevésbé lesz áttekinthető a program.
    Ugyan át lehet írni a "Try" blokkot valahogy így:

    With New Try: On Error Goto ErrorHandler <...error printer> <...error programozási hiba> <...error programozási hiba> <...error e-mail> <...error programozási hiba> <...error fax> <...error algoritmus> <...error fájl törlés> ErrorHandler: .Catch: On Error Goto 0: Select Case .Number Case # 'előre látható hiba kezelése(nyomtatás) Case # 'előre látható hiba kezelése(e-mail) Case # 'előre látható hiba kezelése (fax) Case # 'előre látható hiba kezelése (fájl törlés) Case Else 'előre nem várt hibák lekezelése End Select: End With

    De így majdnem ugyanazt kaptuk meg, mint amire az első pontban céloztam, nincs előnye és csúnya is.
    Ráadásul a 'Select Case' blokknak vagy nincs hibakezelése (pl. újabb programozási hiba) vagy pedig redundáns, ha van már eljárás szintű hibakezelés.
    Ha másra gondoltál, akkor légyszi egy konkrét példában vázold fel.
    A bevezetőmben említettem, hogy én alapvetően 3 részre tagolom a hibakezelést:
    1. A nem várt hibák kezelése (főleg a programozási hibákra gondolok itt).
    2. Az előre látható hibák kezelése "Try" blokkal (printer, fájl, hálózat, I/O, stb.).
    3. Az előre látható hibák, amikkel nem akarunk foglalkozni, de fusson tovább a program.
    Én nem mosnám egybe ennek a 3 féle hibának a kezelését.

    "Ha a With blokkon belül meghívsz egy másik eljárást amely "On Error Goto"-val beállítja a hibakezelést, akkor már nem fog kiderülni egy esetleg a meghívás elött bekövetkezett hiba."
    Ezt nem értem pontosan.
    A With blokk melyik részére gondolsz?
    Az 'On error Goto ...' előtti vagy utáni szakaszra?
    Esetleg egy konkrét példát tudsz mutatni?
    Mutasd a teljes hozzászólást!
  • Nem akarlak elkeseríteni, de van itt pár dolog ami nem stimmel.

    "On Error Resume Next" miatt csak az utolsó hiba derül ki.

    Ha a With blokkon belül meghívsz egy másik eljárást amely "On Error Goto"-val beállítja a hibakezelést, akkor már nem fog kiderülni egy esetleg a meghívás elött bekövetkezett hiba.

    Mutasd a teljes hozzászólást!
  • Hölgyeim és Uraim!

    Egy láda sört (vagy tejet, kinek mi a jobb) ajánlok fel annak, aki a bevezető hozzászólásomban lévő módszernél jobbat és szebbet tud felmutatni, vagy bebizonyítja, hogy nem jó a működése, vagy bebizonyítja azt, hogy ez nem egy új dolog és valaki más ezt már megvalósította.
    Ezen kívül továbbra is várom a hozzászólásokat.
    Lehetőleg most már olyat, ami építő.
    Mutasd a teljes hozzászólást!
  • Nem küldtél továbbra se egy kódot sem, sajnálom.

    "Én nem ágálok ellene"
    Ennek örülök, bár eddig nem úgy tűnt.


    "Használja bárki egészséggel."
    Nem kell megsértődni, ha továbbra is 'On Error Resume Next'-ben akarod kezelni a hibákat én nem foglak megakadályozni benne.
    Csak légyszi ne terjeszd ezt, mert sok embert megtévesztesz vele.
    Ezt most tényleg komolyan mondom.
    Jobb lenne, ha inkább visszavonnád azt a kódot (ez volna a bölcs a részedről), amit az elején leírtál, mert még az én példámon kívül is vannak korrektebb megoldások arra, mást pedig nem tudtál mutatni.


    "1. nincs benne semmi újdonság"
    Új utasítás tényleg nincs, benne, minden a régi megszokott VB utasításokkal történik.
    Igazándiból, nem is tudom, mi lenne a számodra új.
    Azt viszont igenis kijelentem, hogy lényegét tekintve ugyanazt tudja, mint más programozási nyelvek Try-Catch utasítása, ha nem is olyan elegánsan.


    "2. nem ad túl sokat hozzá a hibakezeléshez."
    Ez körülbelül úgy hangzik, mintha azt mondanád, hogy más nyelvekben sincs értelme a Try-Catch utasításnak, mert nem tud többet, mint a VB hibakezelése.


    "már 1999-ben le lehet ilyet tölteni a netről"
    "Az is hasonló megoldást alkalmazott"
    "egy globális hibakezelő osztályban"

    Biztos vagyok, hogy nem hasonlított rá.
    Vagy tudsz ilyen "Try" blokkra hasonlító példát mutatni?
    Elég egy link is.
    Legalább egy hasonló példát mutass, ha már saját példát nem mutattál.
    Szerintem te inkább valami eljárás szintű error csapdákra gondolsz, amik a nem várt hibákat kezelik.
    A váratlan hibákhoz nagyon jó egy közös hibakezelés, de az más terület, nem ehhez a topichoz tartozik.
    Eleve minek egy globális hibakezelő osztály a kivételkezeléshez?
    Ahány hiba annyi féleképp kell lekezelni a várt hibát.
    Maximum a naplózás meg hasonló dolgok lehetnek közösek, de ez ugyanúgy, ahogy más nyelvekben itt is egyeztethető a kivételkezeléssel, viszont ennek sincs köze ehhez a topichoz.
    Mutasd a teljes hozzászólást!
  • Én nem ágálok ellene, csak leszögeztem, hogy 1. nincs benne semmi újdonság, 2. nem ad túl sokat hozzá a hibakezeléshez. Használja bárki egészséggel.

    Én nem azt mondtam, hogy a saját hibakezelő kódom jobb, hanem azt, hogy már 1999-ben le lehet ilyet tölteni a netről. Az is hasonló megoldást alkalmazott, csak ott 1db globális objektum volt, ami a hibákat egy belső collection-höz adta hozzá (catch->kivétel hozzáadása a gyűjteményhez, finally->utolsó hibát kiszedte a gyűjteményből). Ennek a megoldásnak az az előnye, hogy az egymásba ágyazhatóság mellett lehet rá hivatkozni mondjuk egy globális hibakezelő osztályban is, ahol a hibák alapján dobott eseményeket kezelve lehetett egységesíteni a hibakezelést. A Catch()-be ráadásul opcionális paraméterként bele lehetett tenni a rutin nevét is, illetve meg lehetett határozni, hogy a catch milyen hibákat kapjon el.
    Mutasd a teljes hozzászólást!
  • Megint támadsz és kezdesz flame-be átmenni.

    "Annyit csinálsz csupán, hogy az on error resume next-ben elkapod a hibát, az Err értékét átmented egy változóba, leállítod a hibakezelő működését egy on error goto 0-val, majd egy select elágazásban lekezeled a hibát."
    Pontosan erről van szó, ezt csinálja, más utasításokkal nem is lehetne másképp megoldani a VB-ben.

    "Ez a megoldás mitől struktúráltabb annál, mint amit a VB beépített hibakezelője tud?"
    Továbbra is várom a példádat.

    "A lényegét tekintve a VB beépített hibakezelése is pontosan ugyanazt tudja mint a try-catch blokk"
    Alapba nem tudja ugyanazt.
    De hasonlót ki lehet hozni belőle, én csak ezt állítom.
    Eddig is voltak próbálkozások.
    Én pl. 10 éven keresztül ezt a kódot használtam:

    On Error Resume Next nTest = 1 / 0 'Division by zero! pSaveErr(): On Error GoTo 0: Select Case pErr.Number Case 11 MsgBox pErr.Description End Select

    Ezzel a kóddal többek közt az a baj, hogy nem lehet egymásba ágyazni, hacsak fel nem veszel újabb függvényt (pl. pSaveErr2) és újabb saját készítésű globális error objektumot (pl. pErr2, ami a hibát tárolja).
    Amúgy jó lenne ez is a kivételkezelésre, de nem szép megoldás, mert sajnos nem strukturált, azaz összekeveredhet kettő vagy több hibakezelés. Itt jön képbe a 'With New Try'.


    "Azért annak nem kéne annyira örülni, hogy megoldottad az Err objektum értékének átmentését"
    Bocs, de ez már flame.
    Én nem írtam ilyet magamról, ez nem korrekt a részedről, nagyon jól kell tudnod (gondolom megnézted a weboldalamról letölthető forráskódot), hogy annál azért jobban értek a VB-hez, hogy erre legyek büszke.


    "1999-ben is láttam, szal csak 10 évvel maradtál le!"
    Nem láthattál ilyet még, mert nagyon sokat kerestem rá az interneten, én is nehezzen hittem el, hogy ezt még nem írták meg (vagy legalábbis nem használják).
    Mondhatni, hogy csak egyféleképpen lehet megcsinálni tisztességesen és jól a kivételkezeléshez hasonló dolgot VB-ben.
    Nézd meg se elvenni, se hozzá adni nem érdemes a "Try" blokk felépítéséhez így VB-ben megírva.
    Amennyire pofon egyszerű, annyira jól ki van találva.
    Látszólag tényleg nem nagydolog, minden része ismert és jól érthető, így viszont együtt ebben a felépítésben már sokkal többről van szó, bármennyire is jelentéktelennek tűnik.
    Véleményem szerint ez a legkorrektebb kezelés a várt hibákra VB-ben.
    Azt sajnálom, hogy tényleg nem 10 évvel ezelőtt jöttem rá.


    "pl.: enum definiálása az általános hibákra, hiba "dobása"
    események kiváltásával, catch()-ben paraméterként megadni, hogy mely hibák kezelésére vonatkozzon, stb. Így már tényleg érne valamit a kódod."

    Lehetne vele foglalkozni, de a VB COM objektum környezete nem tárolja szabványosan a hibák kódjait, leírását, stb. ellentétben pl. .Net Framework-kel.
    Ettől függetlenül kivételkezelésre jól használható ez a módszer bármennyire is ágálsz ellene.


    "Az általad kreált kód pont azon a szinten áll meg, ahol az még tök fölöslges"
    Küld el már légyszi a várt hibák kezelésére használt kódodat...
    Elég sokat céloztál már rá, hogy a tiéd jobb és az enyém nem ér semmit.
    Nagyon ódzkodsz tőle, pedig már nagyon kíváncsi lennék rá tényleg.
    Két programozónál ez az igazi közös nyelv, nemde bár?
    Győzzél meg inkább konkrét példákkal összehasonlítva a te megoldásodat az enyémmel.
    Ha nem megy, akkor pedig inkább ne szólj hozzá és ne vegyél el az emberektől egy hasznos dolgot.
    Ha meggyőzöl, akkor pedig az elnézésedet fogom kérni, ezt megígérem.
    Várom a kódodat...
    Mutasd a teljes hozzászólást!
  • Azért nem tetszik, mert előnye 0 és te mégis úgy adod elő, mintha feltaláltad volna a spanyolviaszt! Annyit csinálsz csupán, hogy az on error resume next-ben elkapod a hibát, az Err értékét átmented egy változóba, leállítod a hibakezelő működését egy on error goto 0-val, majd egy select elágazásban lekezeled a hibát. Ez a megoldás mitől struktúráltabb annál, mint amit a VB beépített hibakezelője tud? Semmivel. A lényegét tekintve a VB beépített hibakezelése is pontosan ugyanazt tudja mint a try-catch blokk, ehhez nem adtál hozzá semmi pluszt. és értsed meg, ilyen kódot már 1999-ben is láttam, szal csak 10 évvel maradtál le! Azért annak nem kéne annyira örülni, hogy megoldottad az Err objektum értékének átmentését az on error goto 0 utánra, mert ez meglehetősen triviális feladat.

    Az általad kreált kód pont azon a szinten áll meg, ahol az még tök fölöslges, de továbbfejlesztve tényleg tudna a hiba kezelésben segíteni, pl.: enum definiálása az általános hibákra, hiba "dobása" események kiváltásával, catch()-ben paraméterként megadni, hogy mely hibák kezelésére vonatkozzon, stb. Így már tényleg érne valamit a kódod. Addig csak egy triviális feladat kézenfekvő megoldása.
    Mutasd a teljes hozzászólást!
  • "te is on error resume next hatáskörében kezeled a hibákat"
    Nem ott kezelem.
    Nézd meg jobban a hiba kezelése már az 'On Error Resume Next' hatásköre után történik.
    Az 'On Error Goto ...' feloldja az 'On Error Resume Next' hatáskörét.


    "Nincs itt semmilyen try blokk"
    De van egy With blokk, amit én idézőjelekben "Try" blokknak nevezek és ez egy blokkba zárja az aktuális hiba kezelését.
    Ráadásul az ilyen hiba kezelő blokkok mozgatása, másolása, módosítása sokkal kevesebb hiba lehetőséggel jár, mint a hagyományos megoldásoké (hasonlóan az igazi, "gyári" Try-Catch blokkutasításoknál).


    "err-ben mindig csak a legutolsó lesz elérhető"
    A globális Err objektum elveszíti az tulajdonságait az 'On Error Goto ...' után.


    A hibákat pedig akkor is célszerű naplózni ha "vártak"
    Nem elleneztem a naplózást.
    Az, hogy ki mit akar csinálni még a hibákkal a kezelésén túl, loggolja, e-mailt küld el, kiprinteli, faxot küld el, MsgBox-ot jelenít meg, Stb. az mindenkinek a saját szíve joga és döntése, semmi köze sincs ehhez topichoz.


    "...senki sem állítja, hogy a vb-ben struktúrált hibakezelést valósítottak volna"
    A bevezetőmben az írtam, idézem magamat:
    "hasonlóan egyszerű a használata és lényegét tekintve ugyanazt tudja"
    Ezt továbbra is fenntartom.
    Az pedig, hogy mitől lesz valami strukturált vagy sem az nem attól függ, hogy gyárilag beépített utasítás vagy sem.
    Azzal pedig nem foglalkozok, hogy strukturáltnak nevezik, vagy sem a lényegen nem változtat se így, se úgy.


    "Az interneten található, illetve saját készítésű hibakezelő osztályaim is hasonló elven és módszerrel működnek"
    Továbbra is várom azt példádat, amiben nem az 'On Error Resume Next' hatáskörében valósítod meg a hiba lekezelését.
    Azt hiszem csak így foglak tudni meggyőzni, mert úgy látom, hogy nem igazán mélyedtél bele ennek a "Try" blokknak az előnyeibe és csak folyamatosan támadsz pedig én nem bántottalak ok nélkül
    Konkrét példán jobban megtudlak győzni és viszont azt is elvárom ezek után, hogy te is győz meg engem arról, hogy a te megoldásod vagy a hagyományos megoldások jobbak, elegánsabbak, célszerűbbek, biztonságosabbak, ..., mint az enyém.
    Pro-kontra...
    Várom a kódodat...
    Mutasd a teljes hozzászólást!
  • Bocsi, de te is on error resume next hatáskörében kezeled a hibákat, mert csak így lehet kezelni a hibákat a vb ezen verzióiban. Nincs itt semmilyen try blokk.

    Ha nem használom a try objektumodat, akkor max annyit vesztek, hogy több hiba esetén az err-ben mindig csak a legutolsó lesz elérhető. Az nekem nem ad semmi pluszt, hogy az on error elé még odaírom, hogy with new try, illetve a select-es hibakezelés előtt van egy .Catch().

    A hibákat pedig akkor is célszerű naplózni ha "vártak" (azaz felkészítettem a programot a kezelésükre), hiszen mégiscsak hibák és a rögzítésük hozzásegíthet a probléma okának megtalálásához és kijavításához.

    Az interneten található, illetve saját készítésű hibakezelő osztályaim is hasonló elven és módszerrel működnek, mint a te kódod, csak ezekkel kapcsolatban senki sem állítja, hogy a vb-ben struktúrált hibakezelést valósítottak volna meg. Te meg ezt állítod a saját kódoddal kapcsolatban, ami sajnos nem igaz.
    Mutasd a teljes hozzászólást!
  • Először is ne keverjük össze a váratlan hibák kezelését a VÁRT hibák kezelésével, ezt írtam is.
    A kivételek kezelése, a várt hibák kezeléséről szól, mert számítunk rá és ezért nem is jellemző naplózni őket ellentétben a váratlan hibákkal.
    Persze aki akarja naplózhatja a várt hibákat is, ha szükséges.

    Az előnyét akkor ismered fel a "Try" blokknak, ha megnézed azt, hogy eddig, hogyan kezelted azokat a hibákat, amikre eddig számítottál.
    A te példád hátránya az, hogy a várt hibát az 'On Error Resume Next' hatáskörében kezeled, ami nem egy szerencsés dolog és pláne nem egy szép megoldás (már elnézést).
    Persze lehet, hogy nem így szoktad kezelni a várt hibákat, de akkor küldjél be egy másik program mintát légyszi.
    Szerintem abból egyből észre fogod venni a hátrányát is egy "Try" blokkhoz képest.
    (Biztos vagyok benne.)
    Mutasd a teljes hozzászólást!
  • Én a magam részéről nagyon szeretem a VB6/VBA/VBS triót, de sajnos nem látom, hogy milyen előnyt jelentene ennek az osztálynak a használata a jelen formájában.

    A hibakezelés struktúráltságán semmit sem javít (ugyanúgy az on error-ral kapod el a hibákat), csak a hibák rögzítését könnyíti meg egy picit. Azért csak egy picit, mert még egy egyszerű naplózó funkció sincs benne.

    Ha szigorúan a hibakezelést nézzük, akkor az a VB sztenderd eszközeivel kevesebb kódból megoldható:

    on error resume next
    ...
    nTest = 1 / 0 'Division by zero!
    select case err.number
    ...
    end select

    Ez így nagyon gyenge, pár perces kereséssel ennél jóval nagyobb tudású "hibakezelő" osztályokat lehet találni a kérdéses program nyelvekhez.

    De ez csak az én véleményem.
    Mutasd a teljes hozzászólást!
  • Sziasztok!

    Rég voltam, de úgy érzem, hogy ezt közzé kell tennem.
    Írtam egy nagyon rövid, de szerintem annál hasznosabb programot a régi VB fejlesztők számára, ami lehetővé teszi a manapság strukturált kivételkezelésnek hívott módszert.
    Try-Catch for VB
    Nem olyan szép, mint más modernebb nyelvek "Try-Catch" kivételkezelése, de hasonlóan egyszerű a használata és lényegét tekintve ugyanazt tudja.
    (Kéretik más programnyelveket preferáló fejlesztőket, hogy ne nyissanak flame-t, ez a topic nem erről szól, köztudott, hogy a régi VB-t nem érdemes összehasonlítani a mai modern programozási nyelvekkel.)
    Egyformán működik VBA (Access, Excel, Word, Outlook, stb.), VB 4,5,6 és VBScriptben is.
    Először egy rövid példa a kivételkezelésre VBScript-ben, mert gyorsan áttekinthető és kipróbálható, de szinte ugyanez a kód VB 4,5,6 és VBA-ban is.
    A lényeg a "With New Try" részben van, ami eléggé egy ritkán használt módja a 'With' blokkutasításnak, de itt nagyon hasznos.

    Option Explicit Dim nTest With New Try: On Error Resume Next nTest = 1 / 0 'Division by zero! .Catch: On Error GoTo 0: Select Case .Number Case 11 MsgBox .Description End Select: End With Class Try Private mstrDescription Private mlngHelpContext Private mstrHelpFile Private mlngNumber Private mstrSource Public Sub Catch() mstrDescription = Err.Description mlngHelpContext = Err.HelpContext mstrHelpFile = Err.HelpFile mlngNumber = Err.Number mstrSource = Err.Source End Sub Public Property Get Source() Source = mstrSource End Property Public Property Get Number() Number = mlngNumber End Property Public Property Get HelpFile() HelpFile = mstrHelpFile End Property Public Property Get HelpContext() HelpContext = mlngHelpContext End Property Public Property Get Description() Description = mstrDescription End Property End Class

    - A Try blokkok használatához nem kell semmi féle eljárás szintű deklaráció. Elég csak, ha meg van a hozzá tartózó Try Class.
    - A Try blokkok szabadon másolhatók bárhol a forráskódban, nem kell vinni semmilyen hozzá tartozó deklarációt, mint a régi megoldásokban.
    - A Try blokkok egymásba ágyazhatók különösebb megkötések nélkül.
    - A hagyományos hibakezeléssel is minden további nélkül együtt működik.


    Alapvetően 3 féle hibakezelés van egy programban:
    1. Váratlan hiba, amit debuggolni szeretnénk (error handling, error trapping).
    2. Várt hiba, amit szeretnénk lekezelni (exception handling /Try-Catch/).
    3. Várt hiba, amit nem kell, vagy nem akarunk lekezelni, de a program fusson tovább.

    Erre a három féle hibakezelésre készítettem egy komplett "infrastruktúrát" VB6, VBA és VBScript fejlesztéshez.
    Ez VB6 és VBA-nál 2 COM Add In-t jelenet az imént felsorolt hibák kezeléséhez, forrás kód minták beszúrásával a programba.
    Letölthetőek a fentebb jelzett linken.
    Nagyon egyszerű a használata.
    Remélem hasznos lesz azoknak, akik komolyan gondolják a hibakezelést a régi VB-ben.
    Mutasd a teljes hozzászólást!
abcd