Exceptions from __init__() being caught

[jdlangs]

module X
    __init__() = error("Something went wrong")
end
WARNING: error initializing module X:
ErrorException("Something went wrong")

Why is the exception caught and just a warning message printed? I did some basic searching but could not find any reference or explanation for this. Should I not have the ability to send an error to the top-level if something goes wrong when my module is being initialized?

[ivarne]

I agree, but I haven't seen a good answer.

[jdlangs]

It seems like it's sufficient to add a jl_rethrow(); call to this block. Is there some technical reason that won't work / will cause problems?

ETA: It also appears to work fine when the try/catch is removed entirely.

[StefanKarpinski]

@vtjnash, @timholy, @JeffBezanson – thoughts on this?

[JeffBezanson]

I think there was some desire to prevent an exception in one module's __init__ from stopping others from running. While there is a defined order of initialization, it's not very explicit --- you can't look at the code and see where the exception happened, and which __init__ functions haven't run yet.

However, when starting a standalone program, you would want an exception here to just exit(), so maybe it's fine to just remove the try/catch.

[jdlangs]

Isn't it always dangerous to convert errors into warnings, even for completely third-party code? People will inevitably slip on fixing them and the bugs will get propagated much further than they should be.

Would a possible fix be to allow using/import in a try block?

[stevengj]

+1 for removing the try/catch. If my module imports another module, and the latter module refuses to load, I'd like to halt unless I explicitly put the import in a try block.

[vtjnash]

when importing another module, almost everything is an error (file not found, loading code causes an error, and now __init__ throws an error), except if the module doesn't actually load, that is only causes a warning:

julia> using compat
INFO: Recompiling stale cache file /Users/jameson/.julia/lib/v0.4/compat.ji for module compat.
WARNING: requiring "compat" did not define a corresponding module.

julia> using compat
WARNING: replacing module Compat
WARNING: requiring "compat" did not define a corresponding module.

that seems counter-intuitive, is rather hard to model in precompile, and goes against the general principle of avoiding warnings (and either making that something either fully allowed or fully disallowed)

[stevengj]

@vtjnash, yes, I wondered about that behavior when I saw it. An exception seems better, but I thought maybe there was some case with multiple modules in the same file where a warning might be intended? But I can't think of any concrete example of this at the moment.

[StefanKarpinski]

@vtjnash – I don't understand what your position is. Are you against removing the try/catch or for it? Or are you for it and in favor of making more things that can go wrong during __init__ fatal (e.g. module doesn't actually load).

[vtjnash]

i thought Jeff had a position that there should never be a case where emitting a warning is the intended behavior.

I think there was some desire to prevent an exception in one module's init from stopping others from running.

I think you fixed the order sufficiently so that this is not as much of a concern. When it was originally implemented, the list could contain unrelated modules so it was necessary to run through all of them, but with tkelman@506ecbe, i think it's safe to abort.

to argue the other side, however, I sometimes (with invalid build trees), get errors during startup that some library couldn't be found (such as libgmp). It's currently rather nice that it is non-fatal (although only because I am not intending to use anything from that module). Brainstorming this further however, perhaps in the future, we could some sort of "stub" module that acts as a placeholder for a real module, but which actually holds an error. This might also potentially be an improvement for the following code (among others):

> using Foo
LoadError: threw foobar

# current behavior
> using Foo
# nothing

# possible behavior?
> using Foo
ModuleDefinitionError in Foo: LoadError: threw foobar

# and also?
> Foo.bar
ModuleDefinitionError in Foo: LoadError: threw foobar

[StefanKarpinski]

Was that commit merged? If not, then why not?

[tkelman]

That was from a funny rearranged branch I did for bisecting 10525, I'm pretty sure that commit's on master but has a different sha.

[ivarne]

An __init__ function has the ability to do whatever it likes when it can't find a library. If a warning is more apropriate, it should warn("Missing library") instead of error("Missing library").

[StefanKarpinski]

It was: 1047605. Good.

[jdlangs]

Closed by #12576