Question

I’m observing some strange behavior when using the F# interactive interpreter.

Running the following code:

let getType1 = Type.GetType("namespace.does.not.exist, doesntexistlib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null",false);;
let getType2 = Type.GetType("namespace.does.not.exist, doesntexistlib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null",false);;

results in fsi catching a FileLoadException even though the throwOnError parameter is set to false. The first time it returns a null second time the exception occurs.

Running the same code in a regular program (not interactively) results in expected behavior where getType = null.

Does FSI.exe stop on all exceptions? Is it possible to set FSI to ignore these exceptions?

Answer 1

Based on the stack trace, it looks like FSI is hooking into its AppDomain’s assembly resolution. Unfortunately FSI is throwing the exception itself when it can’t resolve the assembly – this isn’t being generated by framework code, and that’s why your throwOnError parameter isn’t being respected – FSI’s exception is just propagating upwards and then being caught at the top level. To me, this looks like a bug in FSI, but it may be that the available hooks in the AppDomain’s assembly resolution process don’t provide FSI with enough information to determine when it’s okay to throw.

EDIT – If you look into the source file fsi.fs (included in the F# distribution in the source/fsharp/Fsi directory), you can see where this handler is hooked up (it’s in the frighteningly named MagicAssemblyResolution module). It appears that FSI needs to hook into the resolution process so that assemblies registered via the #r directive can be found, but I can’t tell at a glance where things are going wrong, or why no exception is thrown all the way to the top level the first time you try to resolve an invalid assembly.