Fallback when caching fails

[matthid]

See discussion in #1088.

[forki]

so when are we rerunning the script exactly?

[matthid]

When an exception occured in the loading code (from the caching logic). Because if a error happens in user code it is handled here and the function returns false. If this doesn't answer it can you clearify the question?

[forki]

Yes!

So normal build error in user code still fails in first try?

Excellent!
On Jan 21, 2016 9:10 AM, "Matthias Dittrich" [email protected]
wrote:

When an exception occured in the loading code (from the caching logic).
Because if a error happens in user code it is handled here
https://github.com/matthid/FAKE/blob/17463458004722d18530769fc826324532b386f1/src/app/FakeLib/FSIHelper.fs#L318
and the function returns false. If this doesn't answer it can you
clearify the question?

—
Reply to this email directly or view it on GitHub
#1093 (comment).

[matthid]

Yes that's how it's supposed to be, maybe that would be a good test though :)

[matthid]

Well it's not actually that simple, there are a wide range of scenarios where this is not correct, for example: Loading the assembly already executes user code (for example assembly level attribute constructors...). If they throw we will recompile as well... On the other hand if the @main method doesn't exist we assume user code failed. Those are real edge cases though.

[forki]

so what do we do?

[matthid]

Nevertheless I think this is an improvement for now. It quite unlikely that people do such crasy things in their build scripts or that the cache can be loaded, has the type we are looking for, but it is missing the member we search for (maybe with an FCS update, but even then we should see it here first in Bootstrap/Unit tests)

[matthid]

I can add a unit test for the obvious case of user code failing later either in this or a separate PR. If I find some time I might add some edge cases just for the fun of it ;)

[forki]

sounds great