Jens Vestergaard skrev:
> Som selvlært udi VB kommer jeg af og til til kort overfor kodenormer
> og -konventioner (og programteori, men et lader vi lige ligge nu)
Skal det forstås sådan at du ikke har kendskab til andre programmeringssprog
end VB?
> Public MyFunction(objNoget As myClsObject) As Boolean
> On Error Resume Next
> '...kode
> '...kode
> MyFunction = Err.Number = 0
> End Function.
Dette er en måde at håndtere (eller rettere: ignorere) fejl på, som jeg kun
ser anvendelse for i nogle _ganske_ få, specielle tilfælde. Jeg kan faktisk
overhovedet ikke komme i tanke om ét eneste selv.
> On Error Goto FuncErr
> '...kode
> '...kode
> MyFunction = True
> Ud:
> Exit Function
>
> FuncErr:
> MyFunction = False
> Resume Ud
> End Function
Lad mig kommentere:
1) Jeg bryder mig ikke om din konstellation med en label Ud og en Resume Ud
i din errorhandler. Hvorfor dog spilde 2 kodelininer og CPU-cycler under
udførelsen af programmet på at hoppe et andet sted hen, hvor det eneste som
sker er, at funktionen afsluttes. Hvis man ikke havde denne kode, ville
funktionen jo også slutte på ganske normal vis.
2) Hvis man _vil_ have at ens funktioner altid slutter ét og samme sted,
ville jeg nok snarere gøre det anderledes: Sæt en Ud-label lige før End
Function og erstat Exit Function med Goto Ud. Jeg foretrækker dog selv at
have to exit-points i mine procedurer og funktioner. Én til "normal" exit og
én til "error" exit.
3) Du bør naturlig (mener jeg) altid sætte MyFunction = False (eller
lignende) i din errorhandler, idet du jo ikke ved _hvor_ i din kode, at
fejlen er opstået. Hvis MyFunction sættes True, og der _derefter_ kommer en
fejl, vil den kaldende part fejlagtigt kunne tro at alt er gået godt.
4) En af de ting, som jeg prøver at tænke på, når jeg programmerer, er
robustheden af programmet. Det kan godt være at man i 30% af funktionerne
kan barbere en MyFunction = False væk fra errorhandleren, men det betyder så
også, at hvis forudsætningerne for barberingen ændrer sig (ændringer i koden
kræver at MyFunction sættes til False i errorhandleren), så er der en reel
risiko for at programmøren glemmer at indsætte denne kode i errorhandleren.
Især hvis det allerede _er_ indsat i 70% af funktionerne!
5) Noget helt andet er, hvad vil du gøre ved fejlen? Kan programmet godt
tilllade sig at fortsætte eller har fejlen opsættellig virkning på
udførelsen?
Jeg bruger typisk en metode til fejlhåndtering der kunne således ud:
Function Str2Long(ByVal StrVal As String) As Long
On Error GoTo ErrorHandler
Str2Long = CLng(StrVal)
Exit Function
ErrorHandler:
Str2Long = -99999999
ReportError "Str2Long"
Err.Raise Err.Number, Err.Source, Err.Description, _
Err.HelpFile, Err.HelpContext
End Function
Problemet er ofte at man opdager at der er fejl i ens program, men man ved
ikke lige præcis i hvilken procedure/funktion at fejlen opstår. Derfor har
jeg næsten altid en fejl-log i mine programmer. Typisk logger jeg til en
Collection, og når programmet slutter (uanset om det var p.gr.a. en fejl
eller det var en normal afslutning), så tilføjer jeg alle linierne i min
log-Collection til en tekst-fil med yderligere oplysninger om program-start,
version, evt. parametre angivet på kommandolinien m.m.
I den ovenstående funktion ved jeg ikke bedre end at rapportere fejlen
videre.
Hvis det drejer sig om en procedure som forsøger at slette en fil, vil jeg
nok rapportere fejlen således:
Err.Raise cExternalError, Err.Source, "Error " & Err.Number & _
" in " & Origin & " trying to delete file """ & FileName & ""."
& _
vbNewLine & Err.Description, Err.HelpFile, Err.HelpContext
Jeg skylder måske lige at vise hvordan en ReportError-procedure kan se ud:
Sub ReportError(ByVal Origin As String)
LogError "Error " & Err.Number & " in " & Origin & ": " &
Err.Description
End Sub
Så må du selv tænke over indholdet af LogError, men HUSK at du ikke kan
tillade dig at have fejl i ReportError og LogError, for så løber
fejlrapporteringen helt af sporet!
> Hva' siger 'de kloge' om den sag (og lignende)?
Jeg er sgu' (UPS - jeg mener: sørme) ikke særlig klog, men jeg har
programmeret i mange sprog i mange år, så _noget_ er der da hængt ved...
-------
Tomas