Jag hänvisar till tidigare inlägg om 'On Error Go To ..", vilken diskussion inte tycks ha löst det grundläggande problemet. Exemplens connection string skiljer sig åt, det är förklaringen. I det exemplet där din felhantering inte fungerar innehåller connection stringen ett felaktigt attribut ("Default Dir" ska vara "DefaultDir") vilket resulterar i ett ADO-fel som inte hanteras med "On Error". Intressant. Enligt Microsoft SKA man få ett "run-time error" också... Vet inte varför det inte blev så här. Notera att exempelkoden fungerar utmärkt även om det inte kastas ett fel. (Som vidare visar att VBs felhantering är att betrakta som ett skämt...) Niklas ! Ahhhhhhhh Nu tog du i. Normalt sett så vill man arbeta typ så här: Jag tackar för inläggen. Efter att ha läst Niklas inlägg noga så säger jag Fy Faen.Till frågan om 'On Error Go To ...'
Nedanståend sekvens är stansad från 'Connell; Beginning Visual Basic 6 Database Programming'.
-----------
Private Sub cmdErrors_Click()
Dim adoConnection As ADODB.Connection
On Error GoTo AdoError
Set adoConnection = New ADODB.Connection
adoConnection.connectionString = "DBQ=BIBLIO.MDB;" & _
"DRIVER={Microsoft Access Driver (*.mdb)};" & _
"Default Dir=C:\OhNooo\Directory\Path;"
adoConnection.Open
'Remaining code goes here, but of course our program
'will never reach it because the connection string
'will generate an error because of the bogus directory
--------
I sekvensen ovan får jag inte Error att fungera.
Nedansltående sekvens är kopierad från exempelprogrammet till samma formulär.
----------------
Private Sub Command1_Click()
Dim adoConnection As ADODB.Connection
On Error GoTo AdoError
Set adoConnection = New ADODB.Connection
' Open connection to Bogus ODBC Data Source for BIBLIO.MDB
adoConnection.connectionString = "DBQ=BIBLIO.MDB;" & _
"DRIVER={Microsoft Access Driver (*.mdb)};" & _
"DefaultDir=C:\OhNooo\Directory\Path;"
adoConnection.Open
------------
I det här fallet fungerar Error men jag kan inte se någon skillnad på koden. Lösning?Sv: Till frågan om 'On Error Go To ...'
Testa detta:
...
adoConnection.Open
Dim lErr As Long
For lErr = 0 To adoConnection.Errors.Count - 1
Debug.Print adoConnection.Errors.Item(lErr).Description
Next lErr
Sv:Till frågan om 'On Error Go To ...'
Betyder detta då att alla ADO-fel (medvetet) inte fångas upp av On Error?Sv: Till frågan om 'On Error Go To ...'
http://msdn.microsoft.com/en-us/library/ms678380(VS.85).aspxSv:Till frågan om 'On Error Go To ...'
Sv: Till frågan om 'On Error Go To ...'
Hade det inte för att vara du så hade jag sagt att du är ett stort skämt.
Snabbt så ser jag Default Dir och DefaultDir är två helt skilda saker.
Det där djä... ADO är ett stort djä... skämt.Sv:Till frågan om 'On Error Go To ...'
1. Kör kod.
2. Om inget fel händer, gör ingenting.
Dvs
Public Sub DoStuff
Kod
End Sub
Normalt sett anser jag att man inte ska lägga till felhantering, utan se till att fel inte uppstår - alltså, låt säga att du har en kod:
for i = lbound(x) to ubound(x)
Där x är en variant (skippa den diskussionen just nu). Du märker efter ett tag att programmet kraschar på den här raden. (Vilket beror på att x inte blivit dimensionerad till en array). Det finns tre lösningar:
if isarray(x) then
for i = lbound(x) to ubound(x)
Då vet man exakt vad felet är och hanterar det när det uppstår, och kan också ge ett svar på varför det hänt. Eller:
on error resume next
for i = lbound(x) to ubound(x)
if err.number>0 then
...
on error goto 0
Då låter man det bli ett fel men hanterar det där felet uppstår, så man vet fortfarande exakt var felet uppstår. Men det är fan så mycket mer kod. Detta tycker jag ändå är helt ok (i andra scenarier är det inte lämpligt eller enkelt att kontrollera om något går att göra först, och då får man helt enkelt låta det bli ett fel som man sen får hantera direkt).
Slutligen har vi den "vanliga" lösningen:
on error goto Catch
for i = lbound(x) to ubound(x)
Catch:
if err.number = 23 then 'vet inte exakt vilket nummer, men typ så här
...
else
...
Det gör att man hanterar felet i en helt annan del av funktionen - för något som kanske är ett ganska litet fel och som man kan komma runt. Vidare vill man ofta stänga massa grejer i slutet av funktionen, typ:
on error goto Catch
for i = lbound(x) to ubound(x)
Catch:
if err.number = 23 then 'vet inte exakt vilket nummer, men typ så här
transaction.rollback
elseif err.number = 18 then
transaction.rollback
else
transaction.commit
end if
Är det många tänkbara fel blir det bra mycket kod för att alltid köra rollback i varje fel. Då kommer man till slut till antingen:
on error goto Catch
for i = lbound(x) to ubound(x)
goto NoError
Catch:
if err.number = 23 then 'vet inte exakt vilket nummer, men typ så här
...
elseif err.number = 18 then
...
end if
transaction.rollback
goto EndOfFunction
NoError:
transaction.commit
EndOfFunction:
End sub
Eller:
on error goto Catch
for i = lbound(x) to ubound(x)
goto NoError
Catch:
If err.number>0 then
if err.number = 23 then 'vet inte exakt vilket nummer, men typ så här
...
elseif err.number = 18 then
...
end if
transaction.rollback
else
transaction.commit
end if
End sub
Inte speciellt stilig kod, eller hur? Så fort man lägger till felhantering av den här arten i VB blir det bara galet. Exceptions är en mycket mer naturlig modell, även om den också är ganska bristfällig.
Det handlar fortfarande om att du i praktiken gör en catch, men med skillnaden:
1. Du får mycket rikare information om vad det är för fel.
2. Hela goto-harangen är underförstådd.
Alltså (vb.net/c#/c++):
try
kod
catch errortype1
hantera detta
catch errortype2
hantera detta
end try
motsvaras av:
on error goto catch
kod
goto noerror
catch:
if err= 1
elseif err=2
end if
noerror:
(sen är ju haskells lösning den enda riktigt rimliga, men det är ju en helt annan fråga).Sv: Till frågan om 'On Error Go To ...'
Att jag inte hört av mig tidigare beror på att jag flyttat från landsbygd till en stad i centrala Skåne. Tidigare var jag beroende av att E.On levererade el, vilket man inte alltid gjorde, eller att åskan inte slog ned på fälten runt bostadshuset.
På den här platsen (i ett villaområde) har det tagit mig nästan tre månader att få ett telefon- och bredbandsabonnemang genom Telias försorg att fungera på det sätt jag varit van vid.
Jag skall nu sätta mig in i vad ni skrivit men återkommer säkert med nya problem.
Mvh
Hans NybergSv:Till frågan om 'On Error Go To ...'
Det var en djävul att krångla till det.
Skall det vara så djä... svårt Phuuuuuuuuu.
Kvalificerat djä trams. Skriv program som funkar för dig och dina närmaste.
Har gjort flera prog där jag fångat fel/buggar så djä.. märkligt är det inte.
Säger igen "Kvalificerat djä... trams" Lägg dom pengarna på något bra.
VB:s Goto Error är så precis bra som egentligen behövs. mmmmmmmmmmmm.............