Verify uses of exceptionFree in ExecuteSessionUpdate

[edsko]

See #251 for details.

Some of these should be verified by me, others by @Mikolaj .

[edsko]

Actually, buildExe and co also throw some exceptions, so they are definitely not exception free. This is probably not a good idea, because it exits the session update immediately. We may have to fix this (not high priority, however).

[Mikolaj]

I think buildExe should not throw exceptions. I even catch some and print them to the stderr log file. But it wouldn't hurt double checking, especially for the other tools (I've just caught and fixed that in haddock generation a couple days ago).

[Mikolaj]

Actually, I only catch IOExceptions in buildExe. So, if something really bad happens, an exception can get through. If needed, I can catch all exceptions and log them in the stderr log file.

[edsko]

Aren't there some calls to "error" in there somewhere? Or "fail"? Or both?

[Mikolaj]

Countless (in the tools' codebase).

[edsko]

No, that's not what I mean. In executeBuildExe itself:

        errors = case toLazyMaybe mcomputed of
          Nothing ->
            error "This session state does not admit artifact generation."
          Just Computed{computedErrors} -> toLazyList computedErrors

and

    when (not configGenerateModInfo) $
      -- TODO: replace the check with an inspection of state component (#87)
      fail "Features using cabal API require configGenerateModInfo, currently (#86)."

[Mikolaj]

I must have missed the context. I call many of the tools as libraries, so the exceptions from 'error' calls get through and not as ExitStatus exceptions (which I catch).

[edsko]

I'm confused. I'm saying that executeBuildExe itself throws exceptions, independent of whatever library it is using.

[Mikolaj]

I guess my point was we may eliminate those, but we can't (easily) do that in libraries. That's why I didn't guess you mean our code exclusively.

[edsko]

Well, we need to catch exceptions thrown by the library, although yes, of course, deeply nested calls to error in pure values somewhere could potentially be a problem -- although we don't actually get any pure values returned by these library calls, do we? So that's not something we should be worrying about?

It just seems rather counter-productive to try and catch exceptions thrown by the libraries, because we don't want to interrupt the execution of the session update, but then throw some exceptions of our own?

[Mikolaj]

Another one is here (called in executeBuildExe)

buildDeps mcomputed = do
  case toLazyMaybe mcomputed of
    Nothing -> fail "This session state does not admit artifact generation."
    ...