Kashperuk Ivan: Development tutorial: Extensibility: Replaceable in Chain of Command methods

[belugin]

Цитата:

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

Так и что будет делать пользователь с этим exception?

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

Расширения ISV не должны брать ответсвенности за условия, про которые не знают.

[trud]

Цитата:

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

Вообще как с любой другой ошибкой в софте - репортить программеру.

что за программер? ну т.е. я как конечный пользователь ставлю 2 сертифицированных решения из App store - у меня после этого перестает работать стандартный лукап по складам. т.е. по идее это ошибка MS(у разработчиков решений то все работает)
т.е. что должен суппорт MS делать с такой ошибкой?

[belugin]

Цитата:

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

по идее это ошибка MS(у разработчиков решений то все работает)

То что у разработчика расширения все работает, это не значит что ошибка не его. Например у него может быть локаль EN-US а у пользователя тайская, и он это не учел. Как и возможность наличия расширения.

Я не знаю, как решает такие вопросы саппорт, как и вопросы при любых 3rd party расширениях для всего чего угодно. Наверное должен быть кто-то, кто поддерживает весь комплект в целом. Так же как если у вас антифирус конфликтует с какой-нибудь утилитой вы обращаетесь к сисадмину.

[trud]

Цитата:

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

Как и возможность наличия расширения.

так а как разработчик должен это учесть? т.е. если вы предлагаете генерить исключение, надо наверное и предлагать механизм обработки этого исключения. если механизма обработки нет, зачем тогда его генерить?
вообще вот отличное описание о "будущем" NAV, странно что для АХ не сделают подобное.
russianerpexperience: Как вендор партнёра услышал, или будет ли Россия в облаке: новости о новейшей системе Dynamics 365 'Tenerife' с Directions EMEA 2017

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

[belugin]

Цитата:

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

так а как разработчик должен это учесть? т.е. если вы предлагаете генерить исключение, надо наверное и предлагать механизм обработки этого исключения. если механизма обработки нет, зачем тогда его генерить?

Учесть так - заменять собой метод только если есть полный контроль над условиями перекрытия. Например, проводка относится к типу который введен вами. (тут, кстати, непонятно как это сделать гарантировано - то есть, если другое расширение будет по какому-то другому независимому признаку определять что именно оно должно перекрыть - надо тогда чтобы была гарантия что пространства параметров не пересекается, то есть у метода должен быть ровно один параметр типа enum).

Мне кажется обработка исключений, кроме нескольких, заключается в том, чтобы прервать текущий процесс и вывести сообщение об ошибке.

Цитата:

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

Ну я собственно с этим согласен - если давать менять метод произвольным образом, то это хуже оверлееринга. Надо либо сводить к гарантированно работтающих (в рамках каких-то допущений) либо к оверлеерингу.