in reply to Re^3: Best practices for handling exceptions in die/eval style
in thread Best practices for handling exceptions in die/eval style

I appreciate your tactic and I can understand it.

But it's confusing for me to ignore $@'s contents, I have some Python and C++ background so I prefer to create objects not messages. What if your object's method or object calls eval in somebody's exception handler code but it's not yours?

Replies are listed 'Best First'.
Re^5: Best practices for handling exceptions in die/eval style
by stevieb (Canon) on Aug 29, 2018 at 22:27 UTC

    My paid profession, in part, is Python programming, so I see kind of what you're getting at here. My C++ is limited; I'm more plain C in that regard.

    Nonetheless, it would be great if you could come up with a Python or C++ example here (brief code example) and explain what your concerns are, everyone here would have a good base to work with and we may get a slew of good advice (I always love learning new things). Many of the Monks are proficient with several languages.

    I think enticing others into the equation to provide their own feedback based on a real-world working example would be great if you have the time.

      Hello. It's me again. Sorry for late reply.

      I said about other languages just to clarify my expectations from exception handling mechanism I'll choose after discussing this topic with you and other monks.

      All I want is to have as close as possible exception handling strategy with objects as errors and backtraces printing to STDERR when error cannot be handled by application. Also I want to avoid all pitfalls related with language peculiarities and consider all possible edge cases, This is for elaboration best common strategy for handling exceptions in Python style (or C++), or, better, as in languages with built-in exception system on language level. I know Perl has it too by in its own way.

      Here is code which fails one of the tests on pre-5.14 versions.

      #!/usr/bin/env perl { package Local::Exception; use overload '""' => \&__str__, 'eq' => \&__str_eq__; sub new { my $class = shift; my $obj = {}; bless $obj, $class; $obj->{error} = "Something bad!"; return $obj; } sub __str__ { my $self = shift; return $self->{error}; } sub __str_eq__ { my $self = shift; my $str = shift; return $self->{error} eq $str; } } { package Local::Obj; use feature "say"; sub new { my $class = shift; my $obj = {}; my %args = @_; bless $obj, $class; $obj->{raise} = defined $args{raise} ? $args{raise} : 1; $obj->{localize_glob_var} = defined $args{localize_glob_var} ? $args{localize_glob_var} : 0; return $obj; } sub something_risky { my $self = shift; die Local::Exception->new(); } sub DESTROY { my $self = shift; if ( $self->{raise} ) { if ( $self->{localize_glob_var} ) { my ( $err, $exc ); # Try clause { local $@; unless ( eval { die "Error"; return 1; } ) { $err = 1; $exc = $@; } } # Catch clause if ($err) { 1; } } else { my $ok = eval { die "Error!"; 1; }; if ( !$ok ) { 1; } } } } } use feature "say"; use Test::More tests => 2; sub test_1 { eval { my $obj = Local::Obj->new(); $obj->something_risky(); }; my $err = $@; isa_ok( $err, "Local::Exception" ); } sub test_2 { eval { my $obj = Local::Obj->new( localize_glob_var => 1 ); $obj->something_risky(); }; my $err = $@; isa_ok( $err, "Local::Exception" ); } test_1(); test_2();

      It's one of pitfalls I want to avoid. Maybe I overlooked some other pitfalls, All I want is to take into consideration all possible pitfalls like this.