goto with some arguments

[Anonymous Monk]

Wouldn't it be beautiful if one can write something like this:

if ($this_is_not_right) {
    goto somewhere (error_code => 123, error_msg => 'this is error');
}
do_something();

return;

somewhere:

   show_error_page($::error_code, $::error_msg);

Thanks.

[diotalevi]

I'd normally write that using an exception. Exception::Class is a particularly nice way to get where you're going with that.

use Exception::Class (
    SomethingException => {
        fields => [qw/error_code error_msg/] },
);

.... much later

if ($this_is_not_right) {
    SomethingException->throw(
        error_code => 123,
        error_msg => 'this is error' );
}

---

Seeking Green geeks in Minnesota

[pg]

Thank you, and this is definitely the most ideal, and future direction, although a distribution table is also not a bad idea.

One might argue that there are cases, the usage of goto is beautiful, but:
1. once you use it, the chance you will abuse it is increased.
2. it is mathematically proved that, goto is not needed. Any control flow involves goto, can be rewritten without goto.

[larsen]

I definitely agree with the first point, but I think it's peculiar we're saying "mathematically ... is not needed" in a forum where Perl is the topic. There are a lot of things in Perl that we don't need, (unless is the first example that jumps in my mind). I think that not needed linguistic structures are here to increase expressiveness.

[zby]

> 2. it is mathematically proved that, goto is not needed.
> Any control flow involves goto, can be rewritten without goto.
That's a bit stretched. I mean if the equivalence is the Turing equivalence than you can program with lambda expressionas or POST systems, but when you take into account time complexity, or space complexity and you take into account O(1) differencees then it's not quite like this.

[jordanh]

2. it is mathematically proved that, goto is not needed. Any control flow involves goto, can be rewritten without goto.

"Beware the Turing tar-pit in which everything is possible but nothing of interest is easy." - Perlis, Alan J.: ``Epigramms on Programming'' SIGPLAN Notices, sept (1982), 7-13

[VSarkiss]

I also find this far, far from beautiful. It reminds me of the awful error handling in Visual Basic.

I think goto is a useful construct, but an error handler built on control reaching a label from multiple places, then reacting to a couple of globals (you've got them as globals) is a recipe for disaster. Imagine yourself staring at the output of your show_error_page routine, and realizing that the error_code and error_msg don't match. Now you have another problem: who clobbered them? An error handler whose context information can be changed from different places is too unreliable to be useful.

If all you're looking for is an error handling technique that can receive some state information and not return to the calling context, exceptions are a much better answer, as others have pointed out above.

[jasonk]

Personally, I think it is far from beautiful, it is also far from obvious what you are trying to do, try this:

if($this_is_not_right) {
    @_ = (error_code => 123, error_msg => 'this is error');
    goto &somewhere;
}
do_something();
return;

sub somewhere {
    my(%params) = @_;

    show_error_page($params{error_code},$params{error_msg});
}

---

We're not surrounded, we're in a target-rich environment!

[cfreak]

Why do you need the goto?

&somewhere; is going to do the exact same thing. Personally I agree with derby's comment down the page. The sub somewhere() isn't really needed at all, and the goto is completely pointless IMHO. Pass the parameters directly to your error handler.

Don't get me wrong, there are legitimate uses for goto such as in AUTOLOAD. I just don't believe this is a legitimate use.

Lobster Aliens Are attacking the world!

[BigLug]

Surely that's just the same as:

if ($this_is_not_right) {
    goto_somewhere (error_code => 123, error_msg => 'this is error');
}
do_something();

return;

sub goto_somewhere {
   show_error_page(@_);
   exit; #  ??? Or did you want to come back ???
}

Goto is ugly bad bad bad code.

[larsen]

While it's probably true that unconditional jumps should be avoided, I'm not against goto "a priori". And, since we're talking about Perl's goto, a mention of the goto &NAME idiom is in order:

use strict;
use warnings;

use vars qw/$AUTOLOAD/;

sub AUTOLOAD 
{
    $AUTOLOAD =~ /.*::(.*)/;
    my $name = $1;

    print "It looks like you're trying to call $name...\n";

    no strict 'refs';
    *{ "main::$name" } = 
        sub { 
            print "Hey, I've been called by ", (caller)[0], 
                  ", and here my arguments: @_\n";
        };

    goto &{ "main::$name" }; # The brand new sub can't realize it has
                             # been actually called from somewhere
                             # else
}

foo( "Hello", "World" );
foo( "Howdy, world" ); # I call foo() again, this time it exists

sub bar
{
    foo( "See you, world" ); 
}


bar();

[jdporter]

You can have that, it's just a matter of syntax. To wit:

if ($this_is_not_right) {
    $::error_code => 123;  $::error_msg => 'this is error';
    goto somewhere;
}
do_something();

return;

somewhere:

   show_error_page($::error_code, $::error_msg);

jdporter
The 6th Rule of Perl Club is -- There is no Rule #6.

[derby]

Don't be so negative:

if ( $this_is_right ) {
   do_something();
} else {
    show_error_page( error_code => 123, error_msg => 'error' );
}

-derby

[feanor_269]

not exactly sure how, as I've not played with overloading yet... but overload goto to just send you to the sub you want with those arguments? (if you're deadset on goto, otherwise, just use a sub call to pass arguments.)

feanor_269

[rir]

Last I knew goto is one of the unoverrideable builtins. That is at 5.6.1.

[feanor_269]

There are unoverridable builtins? Learn something new every day. ++

feanor_269

[benn]

Maybe AM meant "Wouldn't it be beautiful if one could write something like this ... in BASIC". That'd be the Basic Monks down the hall sir... :)