Re: Datentyp von Err / Datei öffnen und in einer Subroutine reinschreiben

Hallo Tobias,

Ich möchte eine Routine schreiben, die bestimmte Daten in die gerade
offene
Datei schreibt. Etwa so:

dim nFile as integer
nFile = FreeFile()
open ... as nFile
if writeFile(nFile) = 0 then <kein Fehler aufgetreten> else <Fehler beim
Schreiben>
close nFile

function writeFile(nFile as integer) as integer
print#nFile, "hurra, ich schreibe in die datei"
return err

Was soll denn dieses "return err"?
Return erfordert ein vorangegangenes GoSub und nach dem Return muss ein
SprungZiel/Zeilennummer stehen.
Err ist das ErrObjekt von VB aber kein Sprungziel.


end function

Meine Fragen:
Welchen Datentyp hat err? Integer? oder Variant verwenden?

Err hat den Datentyp Objekt oder genauer

Debug.Print TypeName(Err) -->> ErrObject


Muss ich err überhaupt zurückgeben, oder würde bei der Rückkehr von
der
Sub ein eventueller Err-Wert erhalten bleiben?

Deine Function writeFile würde überhaupt nicht zurückkehren, sondern schon
zur Designzeit von VB wg.

return err

gar nicht akzeptiert werden.

Spricht was dagegen, dass eine Unterroutine in die offene Datei
schreibt?

Solange Du die Datei geöffnet hast und eine Sub oder Function in die
richtige Datei (mit der richtigen Dateinummer) schreibt, spricht nichts
dagegen. Ob es in Deinem Fall sinnvoll ist, ist eine andere Frage.

Das Problem ist, dass verschiedene Programmteile in der Lage sein
müssen, die gleichen Daten zu schreiben und ich die Schreibroutine nur 1x
im
Programm haben will.

Dein Problem scheint eher zu sein, dass Du nicht verstanden hast, wie Fehler
in VB erkannt, behandelt und evtl. an andere (aufrufende) Prozeduren
weitergereicht werden.

Wenn Du eine wasserdichte Fehlererkennung/Fehlerbehandlung haben möchtest,
dann sollten Prozeduren (Sub/Function) die ihrerseits von anderen Prozeduren
aufgerufen werden einen Fehler erkennen, die Fehlerinformationen um den
eigenen Modul- und Prozedurnamen erweitern und an die aufrufende Prozedur
weiterreichen. Diese übergeordnete, aufrufende Prozedur erkennt den Fehler
wieder und reicht ihn dann z.B. an ein zentrale Fehlerbehandlungsprozedur
(ErrHandler) weiter, in welcher dann z.B. eine Fehlermeldung (MsgBox) für
den Benutzer ausgelöst wird, in der z.B. Fehlerinformationen in eine
LogDatei geschrieben werden usw. usw. ...

Hier mal ein Beispiel:

' /// Code in einer leeren Form1:
Option Explicit


Private Sub Form_Click()
Dim Src As String
On Error GoTo Fehler
' ... blablabla
' ... blablabla

Call MySub

' ... blablabla
Ausgang:
' ...Aufräumarbeiten
Exit Sub
Fehler:
With Err
Src = .Source & "; " & Me.Name & ".Command1_Click"
.Source = Src
Call ErrHandler
End With
Resume Ausgang
End Sub

' /// Code in einem Standardmodul Module1.bas
Option Explicit
Private Const mModname = "Module1"

Public Sub MySub()
Dim X As Integer
Dim Src As String

On Error GoTo Fehler
' ... Dein Code
' ... blablabla ...

' nachfolgende Zeile erzeugt einen Fehler
X = 25 / 0

Exit Sub
Fehler:

With Err
Src = .Source & "; " & mModname & ".MySub"
.Raise .Number, Src, .Description, .HelpFile, .HelpContext
End With
End Sub

Public Sub ErrHandler()
' Routine zur zentralen Fehlerauswertung
Dim strBuffer As String
With Err
strBuffer = "Fehler: " & CStr(.Number) & vbCrLf & _
"Source: " & .Source & vbCrLf & _
.Description
End With
MsgBox strBuffer, vbExclamation
End Sub

' \\\ E N T E

Ein Mausklick auf die Form1 löst Sub Form1_Click() aus.
Darin wird die im Module1.bas befindliche Sub MySub aufgerufen.
Zur Demonstration wird darin eine Division durch 0 ausgeführt, was einen
Fehler auslöst.
Dieser Fehler verzweigt wg. "On Error Goto Fehler" in MySub zum Sprungziel
"Fehler:", wo Err.Source um den Modul- und Prozedurnamen erweitert wird und
der Fehler dann erneut ausgelöst wird.

In Form1_Click gibt es ebenfalls ein "On Error Goto Fehler", weshalb dort
nun nach dem Aufruf

Call MySub

zum Sprungziel "Fehler:" verzweigt wird. Dort wird wieder Err.Source um den
Modulnamen (Form1) und den Prozedurnamen (Form1_Click) erweitert und dann
mit

Call ErrHandler

die zentrale Fehlerbehandlungsroutine aufgerufen, welche das Err-Objekt
auswertet, dem Benutzer eine Messagebox anzeigt, Fehlerinformationen in eine
Logdatei schreibt usw., usw.

Nach Abarbeitung des Code in ErrHandler wird in Form1_Click mit

Resume Ausgang

zum Sprungziel "Ausgang:" verzweigt, wo anschliessend z.B. noch irgendwelche
Aufräumarbeiten erledigt werden können und dann die Sub Form1_Click via Exit
Sub verlassen wird.

Dieses Weiterreichen eines Fehlers zur jeweils aufrufenden Prozedur kann
auch über mehrere Prozeduren hinweg erfolgen. Das geht einfach so lange, bis
der Fehler in der ursprünglich anstossenden Prozedur z.B. einer
Click-Prozedur einer Form oder eines Buttons angekommen ist.

Wendest Du dieses Prinzip lückenlos an, wird eine evtl. spätere Fehlersuche
damit ebenfalls sehr vereinfacht, da Du bei jedem Fehler in Err.Source
sofort sehen kannst, welche Prozeduren vom Fehlerort bis hin zum
eigentlichen Auslöser durchlaufen worden sind.

Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tips u. Beispielprogrammen)

.