Re: How can a module intentionally fail to load?

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

Op Do., 9 Aug. 2018 om 02:05 het Sean Conner <sean@conman.org> geskryf:
>
> It was thus said that the Great Dirk Laurie once stated:
> > Op Wo., 8 Aug. 2018 om 19:00 het Gé Weijers <ge@weijers.org> geskryf:
>
> > > 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.
>
>   And to inform the user why the module failed to load (in my case, that
> their version of TLS is lacking a feature required for use).

So your module could return an error object instead of a module table,
and the documentation could say it does that.

-----[ my-tls.lua / loaded as a module ]----
--[[
Usage:
   my_tls = require "my-tls"
   if my_tls.errormessage then
     error(my_tls.errormessage)
   end
]]


local tls = require "org.conman.tls"

        if tls.LIBRESSL_VERSION < 0x2050000f then
          return { errormessage = [[ ??? there's no point in
continuing with loading
          this module, because libtls will not let us
          ??? control the socket.]]
        end