Article 2775 of comp.lang.perl:
Xref: feenix.metronet.com comp.lang.perl:2775
Newsgroups: comp.lang.perl
Path: feenix.metronet.com!spssig.spss.com!news.oc.com!news.kei.com!sol.ctr.columbia.edu!howland.reston.ans.net!torn!nott!bnrgate!nmerh207!friedman
From: friedman@bnr.ca (Barry Friedman)
Subject: Re: No way to check dbm return code?
Message-ID: <1993May14.023048.4943@bnr.ca>
Reply-To: friedman@bnr.ca
Organization: Northern Telecom, Ltd.
Sender: usenet@bnr.ca (Usenet System)
References: <1993May13.025430.15717@bnr.ca> <MERLYN.93May13101049@kandinsky.intel.com>
Date: Fri, 14 May 1993 02:30:48 GMT
Lines: 47

merlyn@ora.com (Randal L. Schwartz) writes:
>
>You don't say what you want worked around!
>
>You can't change the fundamental nature of DBM, because that would
>make it incompatible with existing maps.  Only so many keys to a hash
>value... that's life.
>
>If you don't want an error message, just don't print it. :-)

I'd better restate the problem in case the original article wasn't clear.

  1) Ndbm can return a -1 error code in case of failure.

  2) Perl prints an error message and continues.

  3) This error condition cannot be detected by the program unless it is
     monitoring it's own stderr.

  4) eval doesn't return an error code ($@) and an undef value as
     per the man page.

So the workaround that is needed is either a fix to the dbm handler in
perl to make it conform to the eval error trapping or something I've
overlooked.

This was the example:

  #!/usr/local/bin/perl 

  dbmopen(%T,"testdbm",0666);
  $v ="x" x 1024;
  eval q!$T{"a"}=$v;!;

  if ($@) {
    print "failed: ".$@;
    exit;
  } 
  dbmclose(%T);

In this case the eval returns $v and the 'print "failed  .. is
never executed.

Regards,
--
Barry Friedman
friedman@bnr.ca