On Friday, August 30, 2002, at 03:32 PM, _brian_d_foy wrote:
> In article <[EMAIL PROTECTED]>, > David Wheeler <[EMAIL PROTECTED]> wrote: > >> On Thursday, August 29, 2002, at 09:48 PM, Dan Sugalski wrote: >> >>> Right, which is why I'd call it like: >>> >>> if (!do_script_thingie()) { >>> print $some_error_message_or_other, $@, "\n"; >>> next; >>> } >> >> Over and over again for every function call? > > shouldn't the application programmer get to decide that? the module > doesn't know enough about what the programmer is doing to make > those sorts of decisions. > This isn't a difference between return-error and throw-exception programming. The caller gets to make the decisions in either situation. The difference is primarily in the cases when a programmer *forgets* to handle an error. Uncaught exceptions force you to take notice, whereas uncaught error values don't do much of anything. They just let some other problem happen later. Zillions of times, I've wished I could change open() into a function that dies upon failure, so I could just write open my($fh), "> foo.txt"; everywhere, rather than my $file = "foo.txt"; open my($fh), "> $file" or die "Can't open $file: $!"; .. Anyone who's read comp.lang.perl.misc for very long probably wishes the same thing. ;-) The Fatal.pm module gets pretty close to this, actually, but ideally it should be a lexically-limited pragma or something. I don't think Fatal.pm would scale very well to large applications, even though that's where it *should* help the most. -Ken
