Странное поведение Fsi.exe - PullRequest
       6

Странное поведение Fsi.exe

1 голос
/ 08 января 2010

Я наблюдаю странное поведение при использовании интерактивного переводчика F #.

Выполнение следующего кода:

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);;

приводит к тому, что fsi перехватывает FileLoadException, даже если для параметра throwOnError установлено значение false. Первый раз, когда он возвращает ноль, второй раз, когда происходит исключение.

Запуск этого же кода в обычной программе (не в интерактивном режиме) приводит к ожидаемому поведению, где getType = null.

Останавливает ли FSI.exe все исключения? Можно ли настроить FSI на игнорирование этих исключений?

1 Ответ

2 голосов
/ 08 января 2010

Исходя из трассировки стека, похоже, что FSI подключается к разрешению сборки своего AppDomain. К сожалению, FSI выдает само исключение, когда не может разрешить сборку - это не генерируется кодом инфраструктуры, и поэтому ваш параметр throwOnError не соблюдается - исключение FSI просто распространяется вверх, а затем перехватывается на верхнем уровне. Для меня это выглядит как ошибка в FSI, но может случиться так, что доступные хуки в процессе разрешения сборки AppDomain не предоставляют FSI достаточно информации, чтобы определить, когда можно бросить.

EDIT - Если вы загляните в исходный файл fsi.fs (включенный в дистрибутив F # в каталоге source / fsharp / Fsi), вы увидите, где подключен этот обработчик (он находится в страшно названный MagicAssemblyResolution модуль). Похоже, что FSI необходимо подключиться к процессу разрешения, чтобы можно было найти сборки, зарегистрированные с помощью директивы #r, но я не могу сразу определить, где что-то идет не так или почему не возникает исключение вплоть до верхний уровень при первой попытке исправить недопустимую сборку.

...