[tz] tzcode error handling
scs at eskimo.com
Mon Dec 11 22:25:59 UTC 2017
> Steve Summit wrote:
>> Patch 1 optionally prints some simple, straightforward error
>> messages if a requested zone can't be loaded.
> Emitting human-orineted messages is a crap way for library code to
> signal an error. It means...
Everything you say is true, but:
> There is already a defined way for localtime() et al to report an error:
> they can return NULL. This doesn't give much information, but...
That's crap, too. (It gives basically one half of one bit of
True story: I was moved to write the (allegedly) improved
error-handling code when I wrote some tz-using code a while back
(a test suite which has unfortunately languished), and submitted
it to tz, and none other than Paul Eggert couldn't get it to work
at first, because he neglected to update TZDIR in the tzcode
Makefile to match the location of his test system's tz files, and
it took him and me a couple of days and a several rounds of email
to figure out the problem.
I submit that the current situation doesn't just give "not much
information", it gives no useful information at all. It's like
the old MS-DOS systems that printed "no such file or directory,
or access denied, or illegal pathname" (or whatever it was) when
the mkdir command failed.
Yes, global modes and static data are poor for library functions.
Yes, a modern interface would "fill a somewhat-user-parseable
structure describing the error" and return it. But remember:
localtime() et al. are not modern interfaces! And they're
already laced with global modes and static data. (And to my
mind, "not modern" is not even pejorative, here. We wouldn't
still be using localtime et al. if they didn't work well enough,
most of the time.)
But with all of that said, I suppose that a program that wanted
to fail less quietly on misinstalled or misconfigured tz data
could, instead of calling this new tz_set_warn_func() first, call
a hypothetical new tzset_with_error(&errorinfo) first, followed
by the requisite print_tz_error(&errorinfo, locale), or whatever.
(What I don't want to do is force such a program to change all of
its localtime and gmtime and mktime calls, since there may be
arbitrarily many of those.)
More information about the tz