Re: How can a module intentionally fail to load?

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

Op Ma., 13 Aug. 2018 om 18:51 het Gé Weijers <ge@weijers.org> geskryf:

> The suggestion was make 'require' return some kind of encoded error, which would then have to be checked. That's a change of behavior from the way 'require' normally works, which is not a good thing. Adding unexpected behavior to a well-known interface is a likely source of bugs. 'require' can also only return one value only, so you will have to come up with a non-standard way to encode an error return. I work with large code bases, and this kind of cleverness comes back to haunt you most of the time.

I cannot agree that returning 'false' is "a change of behavior from
the way 'require' normally works". At most it is a change in the way
that _you_ use 'require'.

The way 'require' normally works is:
(a) If the module cannot be found, throw an error.
(b) If the module returns nothing (or nil), return 'true'.
(c) If the module returns any other value, return that value.

The way most slightly paranoid people use it, is

ok, mymod = pcall"mymod"
if not ok then --[[some customized error handling]] end

The point of returning "false" is that this way of using it catches
the error. There is no prescription as what a module should return:
table, userdata, function, string, even number are plausible. You have
to read the documentation of the module to know what it returns. If
that specification says: "The module returns 'false' if during an
attempt to load it, some error other than failing to find the module
occurred" there is absolutely no reason why it cannot return 'false'.