lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Mon, Nov 28, 2011 at 04:03, Jerome Vuarand <> wrote:
> 2011/11/27 HyperHacker <>:
>> On Sun, Nov 27, 2011 at 01:19, steve donovan <> wrote:
>>> On Sun, Nov 27, 2011 at 10:06 AM, HyperHacker <> wrote:
>>>> previous error loading module 'foo'". How can I see what the previous
>>>> error was?
>>> By looking at the second returned value from pcall(require,'foo').
>>> steve d.
>> Well I meant without doing that; i.e. someone somewhere earlier in the
>> program already did that pcall() and it failed and now I'm trying to
>> load the module a second time and want to know what went wrong.
>> Anyway, I guess the solution should have been obvious: just set
>> = nil and require() will throw the original error
>> again.
> I may be wrong, but I believe that "require" is not behaving very well
> with regards to module loaders throwing errors: these errors are not
> supposed to be recoverable. You have two bits of code going on here.
> First the "require" code itself, that for sure was run partially (only
> whatever comes before calling the loader, not everything that comes
> after). And the module loader code, that thrown the error. You can
> probably look at the "require" implementation, and figure out what
> needs to be "cleaned" if the loader throws an error. But you may have
> to clear some things modified by the partially executed module loader
> function too.
> It would be nice if "require" did handle errors in the loader, and
> cleaned its state itself before re-throwing the error, but that would
> require a mechanism to actually re-throw a caught error, which is not
> currently possible in Lua. You can catch it, clean your stuff, and
> throw a new error (with the same message), but then whatever error
> handler was set outside (for example if you xpcalled require with one)
> will be called at the wrong spot (ie. where "require" is calling
> "error"/lua_error, not at the actual error point in the module
> loader).

Hmm, I wonder if error() with no arguments (or a level of -1?) could
re-throw the previous error? That would be a useful ability...

Sent from my toaster.