Re: Dealing with exit in a Modulino

[Yitzchak Scott-Thoennes]

On Sat, Mar 29, 2008 at 04:44:28AM -0700, Marc Girod wrote:
> The problem is then: how to return to the caller context
> (when there is one, i.e. when I do not choose to exit),
> instead of to the caller of my exit subroutine?
>
> Some kind of exception mechanism.

Something like this (completely untested):


use Test::More tests => ...;

my $exitcode;
sub script_call(&) {
    my $code_to_test = shift;
    undef $exitcode;
    return &$code_to_test();
EXIT_HOOK:
    return;
}

BEGIN { *CORE::GLOBAL::exit = sub { $exitcode = shift; goto EXIT_HOOK } }

use Your::Script;
is(script_call { Your::Script::startup() }, "OK");
is($exitcode, undef, "didn't exit on startup);

script_call { Your::Script::shutdown() };
is($exitcode, 0, "exited on shutdown");

# calls to exit not laundered through script_code end up here
EXIT_HOOK: CORE::exit $exitcode;

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
Yitzchak Scott-Thoennes
<sthoenna@...>], who wrote in article <57076.71.35.169.249.1207529291.squirrel@...>:

> Something like this (completely untested):
>
>
> use Test::More tests =3D> ...;
>
> my $exitcode;
> sub script_call(&) {
>     my $code_to_test =3D shift;
>     undef $exitcode;
>     return &$code_to_test();
> EXIT_HOOK:
>     return;
> }
>
> BEGIN { *CORE::GLOBAL::exit =3D sub { $exitcode =3D shift; goto EXIT_HOOK=
>  } }

Never use goto() in Perl.  Did you see the implementation?

If something like this would be *required* I would use

  EXIT_CATCH: {
    return &$code_to_test();
  }
  return;

and

    last EXIT_CATCH;

in CORE::GLOBAL::exit...  Otherwise I would just eval{} and die
"EXIT_CATCH\n";

Hope this helps,
Ilya

[Yitzchak Scott-Thoennes]

CC'd to Ilya Zakharevich

On Sun, April 6, 2008 7:19 pm, Ilya Zakharevich wrote:

> Never use goto() in Perl.  Did you see the implementation?
>
> If something like this would be *required* I would use
>
> EXIT_CATCH: {
> return &$code_to_test(); }
> return;
>
> and
>
> last EXIT_CATCH;

That seemed cleaner to me too, but I didn't like wrapping the whole
test script in a bare block to provide the fallback for exits that
hit the override but not the sub designed to catch them.

Yes, the goto code is gnarly, but so is a lot of perl.  I don't
consider that reason to avoid it.  Do you have some reason other
than the implementation?

> in CORE::GLOBAL::exit...  Otherwise I would just eval{} and die
> "EXIT_CATCH\n";

That would work so long as the called code isn't itself exiting
in evals.

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
Yitzchak Scott-Thoennes
<sthoenna@...>], who wrote in article <36726.71.35.169.249.1207550453.squirrel@...>:

> > If something like this would be *required* I would use
> >
> > EXIT_CATCH: {
> > return &$code_to_test(); }
> > return;
> >
> > and
> >
> > last EXIT_CATCH;
>
> That seemed cleaner to me too, but I didn't like wrapping the whole
> test script in a bare block to provide the fallback for exits that
> hit the override but not the sub designed to catch them.

                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Cannot parse this.

> Yes, the goto code is gnarly, but so is a lot of perl.

I do not know anything so ghosty as goto().

> I don't consider that reason to avoid it.  Do you have some reason
> other than the implementation?

There is no definition what it is it does.  The implementation DEFINES
the semantic; it is this defined SEMANTIC which is sick.

> > in CORE::GLOBAL::exit...  Otherwise I would just eval{} and die
> > "EXIT_CATCH\n";
>
> That would work so long as the called code isn't itself exiting
> in evals.

True...

Ilya