Jacinta Richardson <[EMAIL PROTECTED]> writes:
>Ed Avis appears to be asking for the LWP::Simple functions to die on
>failure rather than return a false value. The advantage to this method
>is that instead of writing:
>
>do_this() or die "can't do_this...";
>the programmer merely writes:
>
>eval {
> do_this();
> do_that();
> do_this_other_thing();
> do_something_else();
>}
>die $@ if $@;
Yes, or without the eval {} block for simple programs that just want
to bail out on the first error.
However that was not my main motivation for suggesting exceptions.
The best reason is to give helpful error messages to the user. A
binary, yes or no exit status from get() is very little help when
printing an error message. An exception can say exactly what is
wrong.
>I do agree that introducing globals is a bad idea, even to handle
>usable error reporting. Perhaps there's a better solution for this
>problem... although I get the impression that your solution would be
>not to use LWP::Simple, and maybe that is a better approach.
Myself, perhaps I am being naive or over-optimistic, but I don't see
why it is not possible to make a library that is simple to use _and_
supports decent error reporting. Indeed the 'simple' interface is the
one that needs good error handling most of all. It should be easy to
do the right thing - and IMHO the right thing is always to give a full
error message rather than just 'download failed'.
>For what its worth, I understand that changing the behaviour of a
>well used library from relying on return values to using exceptions
>is ludicrous.
Yes, one can't break backwards compatibility like that.
A 'raise error' flag, similar to what DBI uses, would be lovely.
--
Ed Avis <[EMAIL PROTECTED]>
