Re: How can a module intentionally fail to load?

[Dirk Laurie <dirk.laurie@...>]

Op Wo., 8 Aug. 2018 om 19:00 het Gé Weijers <ge@weijers.org> geskryf:
> On Wed, Aug 8, 2018 at 1:49 AM Dirk Laurie <dirk.laurie@gmail.com> wrote:
>> The return value 'false' is an idiom that does not prevent 'require'
>> from trying to reload a module, but at the same time allows your
>> program to test whether there has been a previous unsuccessful
>> attempt.
>
> I don't see a whole lot of use for this, if a module fails to load retrying is not going to help much in almost all use cases, except where you're loading components on demand. In that case I would suggest writing a wrapper around 'require' to get the behavior needed.

An idiom is a way of using language. It is not necessary for an idiom
to have a whole lot of use. It is only necessary that one is
consistent in how the idiom is used.

But I think you (and Daurnimator) miss the utility of 'false', so I'll
continue this reply.

> One downside I see is that the reason for the error is not reported, 'false' does not tell you much, and 'require' returns only one value. If there's one thing I try to avoid is programs that fail silently.

I use 'false' to mean that the module encountered an unanticipated
reason for failing to do what was asked. It is quite usual in Lua not
to raise an error, but to return nil, e.g. io.open. But you can't do
that with 'require':  modules do not need to return anything. They
could do things to global variables. If you return nil or nothing,
'require' translates that to 'true': there is nothing wrong. 'false'
is just the opposite of 'true': something is wrong.

Although 'require' returns only one value, it often puts stuff into
'package.loaded', not in the global environment, for you to require as
needed. For example, Penlight loads pl.util, pl.import_into and
pl.compat. Only pl.util is globally visible as util. Such a package
could profitably use 'false' to indicate that a particular submodule
is not available.

> Another downside of returning 'false' is that you have to test the return value of each 'require', which just clutters up modules, and in the case that 'require' can't find the module it'll throw an error anyway. This creates an interface that reports failures in two different ways, which makes the code handling the error more complicated.

I find myself testing the return value more often than not, even duck-typing it.

But you don't always want your module to raise an error, sometimes you
want your program to have control over what happens, maybe execute a
fallback.

Anyway, If you have no use for this, don't add it to your idiolect. It
just seemed to me to be tailor-made for the OP's situation: to
intentionally dail to load.