Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 7 of 7
  1. #1
    Master Coder
    Join Date
    Apr 2003
    Location
    in my house
    Posts
    5,211
    Thanks
    39
    Thanked 201 Times in 197 Posts

    strange cgi Carp error

    HI,

    I am entering data to my MySQL database in an eval statement. the eval error message is this:

    Code:
    aborted because at /usr/lib/perl5/5.8.5/CGI/Carp.pm line 314.
    my searching shows that it is to do with the mail server but I am not running any code that should connect to it.

    the sub routine is this

    Code:
    sub insert_languages_in_business{
    
       my ( $connect
          , $business_id
    	  , $languages
    	  ) =@_;
    	  
      my @languages_abbr = @$languages;
      print qq( languages_in_businesses : @languages_abbr);
    
      my $sth = $connect->prepare("
      INSERT INTO languages_in_businesses
      ( business_id
      , language_abbr
      )
      VALUES ( ?, ? )
      ") or die "prepare statement failed: $DBI::errstr\n";
    
        foreach my $language_abbr ( @languages_abbr ){
    	    $sth->execute( 
                   $business_id
                 , $language_abbr	
    	    ) or die "execute statement failed: $DBI::errstr\n";
      
        }
    
    return;
    }
    Can anyone please recommend my next step?

    bazz
    "The day you stop learning is the day you become obsolete"! - my late Dad.

    Why do some people say "I don't know for sure"? If they don't know for sure then, they don't know!
    Useful MySQL resource
    Useful MySQL link

  • #2
    Super Moderator
    Join Date
    May 2005
    Location
    Southern tip of Silicon Valley
    Posts
    2,877
    Thanks
    2
    Thanked 164 Times in 159 Posts
    That can't be the complete error message.

    You don't have an eval statement in the code you posted so I assume you're calling this sub within the eval block. What else is the eval block doing? If the failure is due to this sub, then either the prepare or execute statement failed. Which one was it?

  • #3
    Master Coder
    Join Date
    Apr 2003
    Location
    in my house
    Posts
    5,211
    Thanks
    39
    Thanked 201 Times in 197 Posts
    Hi Fishmonger

    the eval block is like this ( but with other subs being triggered as well).

    Code:
    eval {
    insert_languages_in_business( $connect
                                           , $business_id
                                           , $language
                                           ) or die "$!";
     $connect->commit;
    };
    
      if ($@) {
          warn "Transaction aborted because $@"; 
    	  my $session_header = $session->header;
    	  print $session_header;
    	  print qq( aborted because $@);
              $connect->rollback; # undo the incomplete changes
         
      }
    the sub is as above. What I realised after posting was the error message would not display - and the script would run fine, if the error code was removed from the sub trigger.

    Was my inclusion of that error a needless duplication, given that the eval would output any error in the process?

    bazz
    "The day you stop learning is the day you become obsolete"! - my late Dad.

    Why do some people say "I don't know for sure"? If they don't know for sure then, they don't know!
    Useful MySQL resource
    Useful MySQL link

  • #4
    Super Moderator
    Join Date
    May 2005
    Location
    Southern tip of Silicon Valley
    Posts
    2,877
    Thanks
    2
    Thanked 164 Times in 159 Posts
    Yes, I'd say that you have/had needless duplication of the error handling. IMO, eval should only be used in cases where you don't have control over the error handling. With respect to your DB calls, you have full control over the error handling, so issuing a die then trapping that die doesn't make much sense to me.

    One of the issues with using eval, especially when the block is doing multiple things, is that you could have multiple problems, but since $@ is being overwritten each time, you can't be sure at what point the first error occurred or what part of the stack the error is referring to.

    I'm not sure about your version of CGI/Carp, but with mine (3.45) the section of code that the error message refers to is this:
    Code:
    #use Carp;
    BEGIN { 
      require Carp; 
      *CORE::GLOBAL::die = \&CGI::Carp::die;
    }
    My suggestion is to rework your error handling. Take out the die statements on those db calls and turn off RaiseError and possibly PrintError. Then test the return of each call as they are being made and a) issue a warning message, b) issue a rollback, and c) return early if needed and send back a proper return value of either 0 or undef.

    Those are the first level minimum suggestions. If you want more robust error handling, then look into using one or more of these modules.
    Exception::Class
    Error::Exception
    TryCatch
    Try::Tiny

  • #5
    Master Coder
    Join Date
    Apr 2003
    Location
    in my house
    Posts
    5,211
    Thanks
    39
    Thanked 201 Times in 197 Posts
    Thanks Fishmonger.

    I was using an eval to make sure that a range of inserts to my db, would roll back if any of them failed. And if it failed, the $@, was meant to tell me where it failed. That's how I have been doing it, with apparent success.

    How else can I ensure rollback if a crucial insert fails? loads and loads of additional code, with conditionals, relative to whether the previous inserts took place?

    bazz
    "The day you stop learning is the day you become obsolete"! - my late Dad.

    Why do some people say "I don't know for sure"? If they don't know for sure then, they don't know!
    Useful MySQL resource
    Useful MySQL link

  • #6
    Super Moderator
    Join Date
    May 2005
    Location
    Southern tip of Silicon Valley
    Posts
    2,877
    Thanks
    2
    Thanked 164 Times in 159 Posts
    First, one or two code/style comments.

    Using $connect as var name for your database handle is ambiguous. It doesn't give you any indication of what you're connected to. Is it an ssh session, a telnet session, an ftp session, a filehandle, a database handle, or something else? Var names should always give you (and others that read/maintain your code) an indication of what it holds. So, in this case it would be better to use something like $dbh.

    Breaking up long statements with vertical whitespace is good, but IMO, you seem to over do it a little, especially when the items are not vertically aligned as is the case in your code sample.

    Here's an adjusted version which I think should be a cleaner approach to the error handling.
    Code:
    my $error = insert_languages_in_business($dbh, $business_id, $language);
    
    if ( ! $error ) {
        $dbh->commit;
    }
    else {
        print $session->header;
        print "Transaction aborted due to: $error"; 
        $dbh->rollback; # undo the incomplete changes
    }
    
    sub insert_languages_in_business {
    
        my ($dbh, $business_id, $languages) = @_;
    
        my @languages_abbr = @$languages;
        print qq( languages_in_businesses : @languages_abbr);
    
        my $sth = $dbh->prepare("INSERT
                                INTO languages_in_businesses(business_id,
                                                             language_abbr)
                                VALUES ( ?, ? )")
        or return "prepare statement failed: $DBI::errstr\n";
    
        foreach my $language_abbr ( @languages_abbr ) {
            $sth->execute($business_id, $language_abbr)
            or return "execute statement failed: $DBI::errstr\n";
        }
    
        return undef;
    }

  • #7
    Master Coder
    Join Date
    Apr 2003
    Location
    in my house
    Posts
    5,211
    Thanks
    39
    Thanked 201 Times in 197 Posts
    Thanks Fishmonger,

    That's a great help.

    Now to test it myself....

    bazz
    "The day you stop learning is the day you become obsolete"! - my late Dad.

    Why do some people say "I don't know for sure"? If they don't know for sure then, they don't know!
    Useful MySQL resource
    Useful MySQL link


  •  

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •