DAX2009, try / catch не перехватывает исключение (не в транзакции)

[AR®]

Собственно, код:

        try
        {
            c = new DictClass(className2Id(ClassName)).makeObject(params);
        }
        catch(Exception::Error)
        {
            error(strfmt("Не удалось создать экземпляр класса %1", ClassName));
        }

В catch() пробовал написать разные Exception или вообще не писать ничего - не помогло.
Суть в том, что надо отловить случай передачи несуществующего ClassName или неправильного количества / типов параметров в makeObject().
Не ловит

[oip]

Потому что некоторые типы runtime-ошибок отловить нельзя. Никак. Например, ваш случай, когда вместо объекта передается null, а потом вызывается его метод, или если вызвать неоткомпилированный метод и прочие подобные случаи. Выход - проверять корректность самостоятельно.

[AR®]

Цитата:

Сообщение от oip

Потому что некоторые типы runtime-ошибок отловить нельзя. Никак.

Плохо

Цитата:

Сообщение от gl00mie

У... это вы, по-моему, заигрались с обобщенным кодом.

По-другому никак. Имя класса для конкретного случая выполнения кода берется из справочника.

Всех благодарю.

[gl00mie]

Цитата:

Сообщение от AR®

Суть в том, что надо отловить случай передачи несуществующего ClassName

Для этого достаточно проверять, что DictClass создался, т.е. завести промежуточную переменную типа DictClass и проверять, что она не равна null после присваивания.

Цитата:

Сообщение от AR®

или неправильного количества / типов параметров в makeObject()

У... это вы, по-моему, заигрались с обобщенным кодом. Используйте более строгую типизацию, "контракты данных", как в 2012-й, тогда и проверять будет проще. Кроме того, что в вашем примере - params, контейнер что ли? С точки зрения makeObject() контейнер params - это один параметр, так что если надо передавать несколько параметров, то это надо делать явно, указывая их в коде через запятую в вызове makeObject(). Поэтому непонятно, как вы подобным кодом собрались контролировать неправильное количество параметров.

[gl00mie]

Я как-то видел реализации, где в настроечные данные прописывался, кроме прочего, идентификатор класса-обработчика. По-моему, вытаскивать в настройки "внутренности" реализации того или иного функционала - это очень пагубный подход. Во-первых, откуда тот, кто выполняет настройку, должен знать название/идентификатор класса-обработчика? Во-вторых, откуда он знает, что со временем что-то не поменяется, и не будет использоваться другой класс-обработчик? Кто в таком случае обновит настроечные данные? В общем, это хорошо для пакетных заданий, потому что там инфраструктура заранее не знает, какой именно наследник RunBaseBatch будет использоваться, и наследников этих может быть сколь угодно много, а для других случаев это опять-таки, по-моему, - очень пагубный подход.

Есть стандартный подход для таких ситуаций: заводится енум с перечислением различных разновидностей чего-нибудь, и делается статический метод, который по значению енума создает и возвращает экземпляр нужного класса-обработчика. Плюсы такого подхода:

• отвязывание настроек от реализации;
• повышение гибкости реализации (сегодня несколько значений енума могут обрабатываться одним классом, завтра - несколькими, по классу на значение);
• возможность использования строгой типизации с контролем на этапе компиляции (метод-конструктор возвращает не абы что, а предположительно наследника определенного базового класса либо класс, реализующий заранее известный интерфейс).