Re: Note on wwwbot.pl in libwww-perl 0.20
bcutter@pdn.paradyne.com
Tue, 2 Aug 94 16:33:00 EDT
> For the request() interface, such a system already exists via the
> wwwerror.pl stuff and the HTTP return values. For others function,
> though, this may be a bit more difficult.
>
> There are a number of problems with such schemes. One is that
> the standard return values sometimes have the effect of obscuring the
> natural interface, such as in routines like allowed() that return a
> (true, false) answer. The problem is that in Perl (like most languages),
> there is only a few values for false (0, '', undef) and an infinite number
> of values for true. The result is that people start using 0 to mean true
> and use negated routines (e.g. notallowed()) just so that they can pass
> back return values -- or, worse, just declare 0 to mean "good" and expect
> all programmers to remember it.
>
> A second issue is whether or not such standard interfaces are actually
> good for the program. Probably the biggest problem with C is that errors
> are often ignored (even fatal errors) because at some level a library
> routine is being used without checking the error handling. Also, when
> an error does occur and is trapped, it's very difficult to find the source
> of that trap, let alone the source of the error. The big advantage of
> just using warn or die is that Perl can tell the user exactly where the
> trap occurred and the message can exactly match the context of the error.
>
> On the other hand, there are advantages to using a centralized error
> system -- message text can be shared, its easier to maintain consistency,
> its easier to maintain human language-independence, etc.
>
> I guess the best thing would be an out-of-band error handler (e.g.
> like onexit()) that could be passed a standard error number, the custom
> message (if any), and the context of the Perl interpreter where the trap
> occurred (I don't know how, but if warn can get it, I'm sure its available
> somewhere). So, who wants to write it?
The onexit() interface would be fine - that would allow me to put in my
hooks to shut down nicely.. I'd like the onexit() routine to have the option
to tell the library/application to ignore the error and keep going (if possible)..
At the risk of further complicating things (something I excel at), It would
be nice if some of the arguments to onexit (and other error handling routines)
include:
Error levels: minor, major and fatal..
Fatal might include static errors like incorrect parameter calls
or system errors like out of memory (although perl will probably
report this first). Could also include Signals like SIGTERM or SIGSEGV
...I couldn't think of good examples of Major errors... the example
that came to mind is unable to connect to proxy server or host, but
that's handed through $response...
Minor might include errors that can be safely ignored...
If this wasn't perl errors might include casting...
or finding that User-Agent is set but without $www'Library..
Essentially - Fatal kills the program after it logs the error.
Major errors can be handled or can kill the program(default)..
Minor errors can be handled or ignored (default)...
The purpose of Minor errors is minor cosmetic errors that should be corrected,
but don't need to be for the program to continue..
(Not passing the $timeout value might be a minor value - it'll substitute it's
own internal default)
...If the error could then be subdivided further, great... although it
probably isn't worthwhile as it will complicate the error reporting interface..
As for the question about warn/die reporting file and line numbers, Perl
replaces the macros
__LINE__
__FILE__
With the current Line and File numbers..
I also like to print out a few levels of the subroutine call trace...
for (0..5) { print "caller($_)=(",join(',',caller($_)),")\n"; }
> p.s. Oh yeah, and make it thread-safe as well. ;-)
Show me a threaded perl, and I'll begin work on the thread-safe libraries..
-Brooks