die() in DESTROY() (Allgemeines zu Perl)

[thread]13587[/thread]

die() in DESTROY()

Leser: 21

Articles: hide open all | hide show old branches

+6 replies
sid burn

2009-05-29 00:41
User since
2006-03-29
1520 Artikel
BenutzerIn
Hi,
ich bin zufällig auf folgendes gestoßen. Nämlich das ein die() Aufruf in einer DESTROY() Methode nicht zum Programmabruch führt. $@ wird allerdiengs gesetzt.
Code (perl): (dl )

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

{ package Error; use strict; use warnings; sub new { bless {}, $_[0] } sub DESTROY { warn "NEIN!\n"; die { error => "NEEEEEEEEEEEIN!" }; warn "NEIN2!\n"; } } { my $error = Error->new(); print "ja\n"; } print "Dürfte nie erscheinen!\n"; if ( $@ ) { print $@->{error}, "\n"; }
Bei der Ausgabe sehen wir dann auch "Dürfte nie erscheinen!" sowie "NEEEEEEEEEEEIN!". Weiß jemand zufällig die Hintergründe warum dies so ist? Und gibt es auch einen Weg wie man einen Aufruf von die() Sterben lassen kann? Bzw. viel wichtiger ich würde auch wollen das man darum ein eval{} machen kann. Und das wenn ein Objekt bereinigt wird es auch eine Exception werfen kann. Ist das anscheind überhaupt nicht Möglich? Weiß jemand näheres?
Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de
- +3 replies
- pq
  
  2009-05-29 09:11
  
  User since
  2003-08-04
  12208 Artikel
  Admin1
  
  DESTROY wird nicht unbedingt sofort nach ende des scopes aufgerufen. siehe perlobj
  Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
  lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
  - sid burn
    
    2009-05-29 10:50
    
    User since
    2006-03-29
    1520 Artikel
    BenutzerIn
    
    2009-05-29T07:11:45 pq
    DESTROY wird nicht unbedingt sofort nach ende des scopes aufgerufen. siehe perlobj
    
    Ah okay danke.
    Okay dass ist natürlich Blöd und das was ich mir vorgestellt habe funktioniert dann natürlich nicht mehr.
    
    Trotzdem frage ich mich warum das die() abgefagen wird. In meinen Fall wird das die() ja noch vor Programmende ausgelöst da der if ( $@ ) { ... } block ja ausgeführt wird.
    Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de
  - betterworld
    
    2009-05-29 12:30
    
    User since
    2003-08-21
    2614 Artikel
    ModeratorIn
    
    2009-05-29T07:11:45 pq
    DESTROY wird nicht unbedingt sofort nach ende des scopes aufgerufen. siehe perlobj
    
    Es wird hier aber (jedenfalls bei mir) offenbar am Ende des Scopes aufgerufen. Das sieht man daran, dass "NEIN!" schon ausgegeben wird.
    
    Ich hatte schon einmal irgendwann die Erfahrung gemacht, dass Exceptions in Destruktoren einfach nicht fatal sind. Das scheint auch der Grund für das Verhalten dieses Scriptes zu sein. Ich weiß nicht, ob es dokumentiert ist. Offenbar wird die Exception einfach ignoriert, abgesehen davon, dass $@ gesetzt wird.
    Lieblingsmodule: IPC::System::Simple, Path::Class
- murphy
  
  2009-05-30 00:01
  User since
  2004-07-19
  1776 Artikel
  HausmeisterIn
  Es erscheint zwar vielleicht im ersten Augenblick merkwürdig, dass ein die in einem Destruktor keinen Programmabbruch bewirkt, aber andererseits sollte man sich ein paar Dinge in Erinnerung rufen:
  
  Ein Destruktor hat den Zweck, externe Resourcen freizugeben oder andere Managementaufgaben am Ende der Lebensdauer eines Objektes wahrzunehmen, die nicht voll automatisch erledigt werden können.
  Es ist nicht klar, wann und in welchem Kontext ein Destruktor aufgerufen wird. Das einzige was feststeht ist, dass er aufgerufen wird, wenn das Objekt zu dem er gehört nicht mehr referenziert wird.
  die ist keine Methode um ein Programm unkonditionell abzubrechen sondern kann auf verschiedene Arten abgefangen werden.
  
  Das bedeutet aber:
  
  Ein Destruktor muss immer irgendwie erfolgreich ablaufen können, wenn das Programm nicht in einen inkonsistenten Zustand geraten oder Resourcen lecken soll.
  Die Hierarchie von Fehlerbehandlungsroutinen um den Aufruf eines Destruktors herum ist unklar. Ein normal ausgeführtes die würde vielleicht irgendeinen völlig unkorrelierten eval-Block mit der Fehlermeldung des Destruktors belästigen und so ebenfalls Verwirrung im Programm stiften.
  Ein Destruktor muss in jedem dynamischen Kontext lauffähig sein, denn der Programmierer hat keine volle Kontrolle darüber wo er aufgerufen wird. Es mag durchaus sein, dass zum Zeitpunkt des Destruktoraufrufes die ohnehin nicht fatal ist.
  
  Für Code der in jedem beliebigen Umfeld korrekt ablaufen soll, und der eigentlich gar nicht fehlschlagen darf, wenn nicht überall die Hölle losbrechen soll, ist das Verhalten das Perl hier an den Tag legt ziemlich sinnvoll. Im übrigen deckt es sich auch mit dem anderer Sprachen wie zum Beispiel Java.
  
  Sollte ein Destruktor wirklich feststellen, dass das Aufräumen des Objektes unmöglich ist und folglich das Programm ziemlich sicher nicht mehr in einen definierten Zustand zu bringen ist, dann ergibt es auch Sinn, wenn er härtere Maßnahmen als die ergreift, um einen Programmabbruch zu erzwingen.
  When C++ is your hammer, every problem looks like your thumb.
- betterworld
  
  2009-05-30 00:48
  User since
  2003-08-21
  2614 Artikel
  ModeratorIn
  Ich habe mir gerade mal den Backtrace angeguckt (eigentlich nur, um zu sehen, ob der Destruktor innerhalb des Kontextes des Blockes, in dem das Objekt zerstört wird, läuft), und da fällt etwas auf:
  
  Code (perl): (dl )
  
  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
  
  use strict; use warnings; use Carp qw(cluck); sub new { return bless{}; } DESTROY { cluck 'cluck'; } sub foo { my $x = main->new; print "before\n"; undef $x; print "after\n"; } foo();
  
  Ausgabe:
  
  Code: (dl )
  
  1 2 3 4 5 6
  
  before cluck at x.pl line 10 main::DESTROY('main=HASH(0x8c383cc)') called at x.pl line 17 eval {...} called at x.pl line 17 main::foo() called at x.pl line 20 after
  
  Aha, da wurde also ein eval-Block reingeschummelt!
  Lieblingsmodule: IPC::System::Simple, Path::Class

View all threads created 2009-05-29 00:41.