¿Qué debo hacer si falla un método de compilación de Moose?

Question

¿Cuál es la mejor manera de manejar una falla en un método de construcción?

Por ejemplo:

package MyObj; 
use Moose; 
use IO::File; 

has => 'file_name' (is => 'ro', isa => 'Str',  required =>1 ); 
has => 'file_handle' (is => 'ro', isa => 'IO::File', lazy_build => 1); 

sub _build_file_handle { 
    my $self = shift; 
    my $fh = IO::File->new($self->file_name, '<'); 

    return $fh; 
} 

Si el _build_file_handle falla para conseguir una manija, el constructor volverá undef, que no la restricción de tipo.

Podría usar una unión en la restricción de tipo file_handle, de modo que acepte un undef como valor válido. Pero entonces, el predicado has_file_handle devolverá verdadero, incluso cuando el valor sea undef.

¿Hay alguna manera de indicar que el constructor ha fallado y que el atributo debe permanecer despejado?

Answer 1

"mejor" es subjetiva, pero usted tendrá que decidir qué tiene más sentido en el código:

1. si puede continuar en el código cuando el gestor de archivo no se genera (es decir, se una condición recuperable), el constructor debe devolver undef y establecer la restricción de tipo en 'Maybe[IO::File]'. Eso significa que también deberá verificar la definición de ese atributo siempre que lo use. También podría verificar si este atributo se construyó correctamente en BUILD, y optar por tomar medidas adicionales en ese punto (como se hizo alusión a friedo en su comentario), p. llamando a clear_file_handle si es undef (ya que un constructor siempre asignará un valor al atributo, asumiendo que no muera, por supuesto).

2. De lo contrario, deje que el generador falle, ya sea lanzando una excepción explícitamente (que puede optar por alcanzar más arriba), o simplemente devolviendo undef y dejando que la restricción de tipo falle. De cualquier forma, tu código morirá; solo tienes que elegir cómo se muere y cuán voluminoso es el rastro de la pila. :)

PS. También puede consultar Try::Tiny, que Moose usa internamente, y es básicamente un contenedor para * la expresión do eval { blah } or die ....

* _{Pero hecho bien! y de una manera genial! (Me parece escuchar un montón de susurrándome al oído de #moose ..)}

Answer 2

¿Hay una manera de señalar que el constructor ha fallado, y el atributo debe permanecer despejado?

No. Esto no tendría sentido, el constructor se disparará si se cleaered el atributo, si se borra dentro del constructor sería simplemente disparar cuando hizo la siguiente llamada a la misma, y ​​permanecer en el aclarado estado. Un desperdicio de mucho trabajo, solo para set-something-if-it-works-and-if-not-continue.

La sugerencia type-union es buena, pero luego tiene que escribir un código que pueda funcionar con dos casos radicalmente diferentes: un identificador de archivo y un manejador de archivo inexistente. Esto parece una mala idea.

Si el manejador de archivo no es esencial para la tarea, probablemente no se comparte entre el mismo ámbito de cosas con acceso al objeto. Si este es el caso, entonces el objeto solo puede proporcionar un método que genere un identificador de archivo del objeto.Lo hago en código de producción. No se empeñe en hacer de todo un atributo perezoso, algunas cosas son funciones de atributo y no siempre tiene sentido adjuntarlas al objeto.

sub get_fh {                 
    my $self = shift;               

    my $abs_loc = $self->abs_loc;            

    if (!(-e $abs_loc) || -e -z $abs_loc) {         
    $self->error({ msg => "Critical doesn't exist or is totally empty" }); 
    die "Will not run this, see above error\n";        
    }                   

    my $st = File::stat::stat($abs_loc);          
    $self->report_datetime(DateTime->from_epoch(epoch => $st->mtime));  

    my $fh = IO::File->new($abs_loc, 'r')         
    || die "Can not open $abs_loc : $!\n"         
    ;                   

    $fh;                  

}                   

Un enfoque totalmente diferente es subclase IO::File, con los metadatos sobre el archivo que desea conservar. Algunas veces esto es efectivo, y una gran solución:

package DM::IO::File::InsideOut; 
use feature ':5.10'; 
use strict; 
use warnings; 

use base 'IO::File'; 

my %data; 

sub previouslyCreated { 
    $data{+shift}->{existed_when_opened} 
} 

sub originalLoc { 
    $data{+shift}->{original_location} 
} 

sub new { 
    my ($class, @args) = @_; 

    my $exists = -e $args[0] ? 1 : 0; 

    my $self = $class->SUPER::new(@args); 

    $data{$self} = { 
    existed_when_opened => $exists 
    , original_location => $args[0] 
    }; 

    $self; 

}; 

Answer 3

No está pensando en un nivel lo suficientemente alto. OK, el constructor falla. El atributo permanece indefinido. Pero, ¿qué haces con el código que llama al usuario? El contrato de la clase indicaba que llamar al método siempre devolvería un IO :: File. Pero ahora está volviendo undef. (El contrato fue IO::File, no Maybe[IO::File], ¿verdad?)

Así que en la siguiente línea de código, la persona que llama se va a morir ("No se puede llamar al método 'readline' en un valor indefinido en the_caller.pl línea 42 . "), porque espera que su clase siga el contrato que definió. El fracaso no era algo que tu clase debía hacer, pero ahora lo hizo. ¿Cómo puede la persona que llama hacer algo para corregir este problema?

Si puede manejar undef, la persona que llama no necesita un identificador de archivo para empezar ... entonces, ¿por qué le pidió uno a su objeto?

Con esto en mente, la única solución sensata es morir. No puede cumplir el contrato que acordó, y die es la única forma en que puede salir de esa situación. Así que haz eso; la muerte es un hecho de la vida.

Ahora, si no está preparado para morir cuando se ejecuta el constructor, deberá cambiar cuando se ejecute el código que puede fallar. Puede hacerlo en tiempo de construcción del objeto, ya sea haciéndolo no perezoso, o reviviendo explícitamente el atributo en BUILD (BUILD { $self->file_name }).

Una mejor opción es no exponer el identificador de archivo con el mundo exterior en absoluto, y en lugar de hacer algo como:

# dies when it can't write to the log file 
method write_log { 
    use autodie ':file'; # you want "say" to die when the disk runs out of space, right? 
    my $fh = $self->file_handle; 
    say {$fh} $_ for $self->log_messages; 
} 

Ahora se sabe cuando el programa se va a morir; en new, o en write_log. Ya sabes, porque los documentos lo dicen.

La segunda forma hace que su código sea mucho más limpio; el consumidor no necesita saber sobre la implementación de su clase, solo necesita saber que puede indicarle que escriba algunos mensajes de registro. Ahora la persona que llama no está preocupada con los detalles de su implementación; simplemente le dice a la clase lo que realmente quería que hiciera.

Y, morir en write_log incluso puede ser algo de lo que pueda recuperarse (en un bloque catch), mientras que "no pudo abrir esta opacidad aleatoria que de todos modos no debería saber" es mucho más difícil recuperar de.

Básicamente, diseñe su código de manera sensata, y las excepciones son la única respuesta.

(No entiendo el todo "son un poco pesado" de todos modos. Funcionan exactamente de la misma manera en C++ y de manera similar en Java y Haskell y en todos los demás idiomas. ¿Es la palabra die realmente tan espeluznante o algo así?)