User Warnungen aus öffentlichen OO Methoden, Konzepte?

[Beat]

Hallo

Ich schreibe an einem Perl modul
Dieses hat Methoden, deren Outpunt zur Printausgabe gedacht ist.

Wichtiger sind mir aber jetzt die Methoden, die lediglich den zustand des Objektes verändern. Ein Output wäre demnach nur als Kontrollausgabe wünschbar.

Derzeit trappe ich mit eval verschiedene Situationen, um im Falle von $@ eine dem User verständliche Message an eine Errorqueue zu hängen.

  
eval{ require "Module\\" . $mod. ".pm" };  
return( $c_self->{'system'}{error} .=  
 'ERROR'.NL.'  
  ( Perl-Modul fuer pc '. $mod .': ' .$mod . ".pm ist in /PC nicht erreichbar)\n$!\n"  
) if $@;  

Falls die Errorqueue besetzt ist, kann man sie sich ausgeben.

Beipielanwendung

use PC::Parser;  
my $obj = PC::Parser->new;  
  
my $error = $obj->initfile( 'some/path/to/initfile' );  
$error and print $error;  

Kurz: Ist in der Methode die Rückgabe nicht undef, so kann sie ausgewertet werden.

Die Frage ist nur, ist das das beste Konzept?
Oder wäre es besser eine Strategie zu verfolgen, die auch bei
Erfolg einen Wert ausgibt? In dem Fall müsste ich wohl einen Array zurückgeben.

Irgendetwas sagt mir, dass es keine schlechte Idee ist, Statuscodes vorzuhalten.

Über Tipps zu bewährten Konzepten wäre ich dankbar.

mfg Beat

[hotti]

Hallo

Ich schreibe an einem Perl modul
Dieses hat Methoden, deren Outpunt zur Printausgabe gedacht ist.

wenns geht vermeide ich die print() Funktion in meinen Modulen.

Erfolg einen Wert ausgibt? In dem Fall müsste ich wohl einen Array zurückgeben.

Oder besser gleich eine Referenz ;-)

Hotti

[Siechfred]

Über Tipps zu bewährten Konzepten wäre ich dankbar.

Ich mache das über Packagevariablen:

package Blabla;  
our $ErrorMsg;  
  
sub nonsense {  
  my $self = shift;  
  my $wert = shift;  
  $ErrorMsg = 'You cheap lousy faggot!' if $wert !~ /$pattern/;  
  return $ErrorMsg ? 0 : 1;  
}

Und im Script:

$instance_of_Bla->nonsense('huh') or die $Bla::ErrorMsg;

Siechfred

[Beat]

Also die Art von Errormessages ist eher so,
wie wenn ein Fehler im HTML nicht zum beenden des Browsers führen sollte.

Ich habe mir jetzt einfach eine eigene Objektmethode (jede Instanz bekommt separate Errormessages) gebastelt.

$obj->initfile( 'file/path' );
$obj->geterror() or $obj->parse($text);

Weil die Ausgabe von $obj->init() und $obj->initfile() ebenfalls eine Ausgabe von Erroressages ist, kann man auch schreiben:

$obj->initfile('file/path') or $parsedtext = $obj->parse($text);

Das ist natürlich sprachlich verworren. Deshalb $obj->geterror();

mfg Beat

[Struppi]

Also die Art von Errormessages ist eher so,
wie wenn ein Fehler im HTML nicht zum beenden des Browsers führen sollte.

Ich hab mir angewöhnt warn() und die() zu verwenden und dann diese Signale im Browser auszugeben (natürlich nur in der Entwicklungsphase).
Was anderes ist es, wenn das weitere Vorgehen von dem Erfolg einer Funktion abhängt. Dann bevorzuge ich einen Rückgabewert als Erfolgs-/Mißerfolgsmeldung.

Struppi.