Thread Nach Instanzieren von Win32::SqlServer ist $@ nach die() leer
(6 answers)
Opened by TheMic at 2011-10-19 17:46
Hallo,
ich bin gerade dabei eine Datenbankverbindungsklasse zu schreiben, die das Modul Win32::SqlServer kapselt. Es funktioniert auch bereits alles. Nur ist mir jetzt beim Testen aufgefallen, dass, wenn das Modul bereits instanziert ist, nach einem die() oder croak() keine Fehlermeldung mehr in $@ steht. Folgender Code funktionert: Code (perl): (dl
)
1 2 3 4 5 6 7 8 9 10 use Win32::SqlServer; eval { die('Fehlermeldung'); my $connection = new Win32::SqlServer(); } or do { print $@; }; #Ausgabe: Fehlermeldung at ... Folgender Code funktioniert nicht: Code (perl): (dl
)
1 2 3 4 5 6 7 8 9 10 use Win32::SqlServer; eval { my $connection = new Win32::SqlServer(); die('test_irgendwas'); } or do { print "_" . $@ . "_"; }; #keine Ausgabe Nun habe ich durch debuggen herausgefunden, dass bei der zweiten Variante noch die Methode DESTROY des Packages Win32::SqlServer aufgerufen wird: Code (perl): (dl
)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 sub DESTROY { my ($self) = @_; delete $my_objects{$self}; # We run the destruction in eval, as Perl sometimes produces an error # message "Can't call method "FETCH" on an undefined value" when the # destructor is called a second time. eval('xs_DESTROY($self)'); unless ($@) { # We must clear internaldata, since Perl calls the destructor twice, but # on the second occasion, the XS code has already deallocated internaldata. # The XS code has problem with setting values in stored hashes, why we do # it. This assignment cannot be in eval, since the STORE method only # permits DESTROY to change internaldata. $$self{'internaldata'} = 0; } } Was macht dieses xs_DESTROY()? Liegt es eventuell an diesem? Wie kann ich umgehen, dass bei der Ausführung des Destruktors des Moduls der Inhalt der Variablen $@ gelöscht wird? Ich verwende übrigens Perl in der Version 5.8 und das Modul Win32::SqlServer in der Version 2.007. Mit freundlichen Grüßen, Michael Last edited: 2011-10-19 20:25:41 +0200 (CEST) |