Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • If the get_connection method returns a handle
    on which RaiseError, was set, just wrap in
    an eval:

    sub GetValues {
          my $a;

          eval {
                  my $dbh = get_connection('databasename');
                  my $sth = $dbh->prepare('Select * from table_name');
                  $sth->execute();
                  my $r;
         
    --
    -derby
  • bail out on error (Score:3, Interesting)

    by jmm (276) <johnNO@SPAMperlwolf.com> on 2003.09.17 11:03 (#24270) Journal
    A lot of the extra code space is the constant testing whether you need to skip the next step because you've already hit an error. Just bail out when the error happens. I also changed it to either return 0, $msg (when an error happened) or else to return 1,@list (when everything worked).
    #------------------------#
    sub GetValues
    #------------------------#
    {
        my $dbh = get_connection('databasename')
          or return( 0, "Failed to get connection to databasename in GetValues" );
        my $sth = $dbh->prepare('Select * from table_name')
          or return( 0, "Call to prepare failed in GetValues" );
        my @a = $sth->execute()
          or return( 0, "Call to excecute failed in GetValues" );
        my $r;
        my @a;
        push @a, $r
            while $r = $sth->fetchrow_hashref;
        return (1, \@a);
    }
    #------------------------#
  • I don't understand why people keep all kinds of status flags and hold off until the end of a routine to "return". If you know that you will do nothing after a failure at:

          if (!$dbh) {
                    $ok = 0;
                    $msg = "Failed to get connection to databasename in GetValues";
            } else {
                    $sth = $dbh->prepare('Se
  • ick (Score:3, Interesting)

    by gav (2710) on 2003.09.17 12:00 (#24273) Homepage Journal

    I find code like this pretty cringe-worthy. If you set RaiseError and HandleError, you can have something this simple:

    sub get_values {
        my $dbh = get_connection('databasename');
        return $dbh->selectall_arrayref(
            'SELECT * FROM table_name', { Slice => {} }
        );
    }

    Isn't that much nicer than 25 lines of code? I'm also not keen on returning flags for errors, you'll just have to write lots of code to check, just die if something bad happened and trap it with eval.

    • Yes, and most of the time, the correct reaction to something bad happening is to die, so you can even drop the eval.
  • The best way I've found is to use RaiseError => 1, which tells DBI to always throw an exception when there is an error. This way, you never have errors go unnoticed. If you want an error to not be fatal, use eval. eval { $dbh->do("DROP TABLE users"); }; if ( $@ ) { my_error_handler( $@ ) } Another method I use is a function that does a little more digging for me before printing it's error message. sub check_dbi_errors ($) { my $sth = shift; return if (!$sth-
    • Hmm, I didn't look and see that the pre tag isn't allowed. bummer.

      The best way I've found is to use RaiseError => 1, which tells DBI to always throw an exception when there is an error. This way, you never have errors go unnoticed. If you want an error to not be fatal, use eval.

      eval {
            $dbh->do("DROP TABLE users");
      };
      if ( $@ ) { my_error_handler( $@ ) }

      Another method I use is a function that does a little more digging for me before printing it's error message.

      sub check_dbi_erro