Задать себе вопрос - а нахрена мне вообще эта DLL. Я примерно на 99.99% уверен, что убедительного ответа на этот вопрос не существует, просто (судя по тому, что я вижу в приведённых исходниках) Вы полны решимости избежать хороших практик и собрать все грабли, которые существуют на этом пути.


Смотря для кого. Для тех, для кого это проблема, писать dll - вообще не очень стиль.


Какой ужас. Если бы так было в самом деле, стоило бы застрелиться.

Это бессмысленное и не нужное условие. Тем не менее, мне было бы любопытно провести опрос - у кого сколько DLL "использующихся разными приложениями" и сколько DLL "использующихся исключительно одним приложением". Что-то мне подсказывает, что список жалующихся на проблемы с DLL практически совпадёт со списком тех, у которых доминирует "одно приложение".


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

И какое из этих трёх условий мешает использовать DLL в нескольких приложениях?

Зачем иголка с ниткой, если есть топор? Меня всегда удивлял этот вопрос. Единственное преимущество BPL - её можно инсталлировать в IDE. Когда это не нужно (то есть в 99% случаев), она не имеет преимуществ - одни недостатки. Так зачем в этих условиях BPL, когда есть DLL?


То есть ты выбираешь ежедневный геморрой ради того, чтобы избежать одной занимающей несколько минут операции, которая случается не каждый год?

Без разумных аргументов - не переубедишь, это точно.

В смысле, то же самое, что в случае dll делается простановкой одной галочки? Ну типа плюс, конечно, но по сравнению с минусами примерно то же, что оловянный солдатик по сравнению со Статуей Свободы.


Скорее всего - привык к геморрою и не считаешь его таковым. Например - поступаешь, как здесь советуют, то есть не выпускаешь исключений из dll и корячишься с кодами возврата. В целом, мне будет проще ответить, если я увижу пару примеров того, что ты считаешь негеморройным кодом.

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

Цель программ, то, для чего вообще их пишут - выполнение бизнес-функций. Например, программа вычисления корней квадратного уравнения должна вычислять корни этого самого уравнения. В идеальном случае она будет содержать только код этого вычисления - и этого хватит, чтобы всегда сработать именно так, как нужно.

К сожалению, у нас пока что не идеальный мир, и в этом не идеальном мире, помимо бизнес-кода, программа должна содержать некоторое количество кода технического. Объявление переменных, проверка диапазонов допустимых значений, обработка исключений.... Это делает программу лучше, но одновременно размазывает, замыливает и маскирует главное - бизнес-логику. Для того, чтобы программа была хорошей (в плане - читаемой, легко сопровождаемой, содержащей как можно меньше ошибок и т. д.) технический код должен быть сколь возможно минимизирован и сколь возможно отделён от бизнес-логики. Будет верным сказать, что из двух инструментов, порождающих эквивалентные программы, лучше тот, который требует меньше технического кода, из двух подходов лучше тот, который при эквивалентном результате требует меньше технического кода.

В частности, коды возврата - очень нездоровая в смысле объёма технического кода практика. Пока программисты их использовали - даже простейшие бизнес-функции кодировались огромными простынями, в которых было очень сложно разбираться. Использовались специальные приёмы кодирования для того, чтобы хоть как-то справляться с этой сложностью. Когда появились исключения - нормальные программисты с восторгом за них ухватились, потому что они дали возможность писать куда более сложную бизнес-логику гораздо короче, гораздо яснее, не в пример сопровождаемее. Благодаря механизму исключений трудоёмкость адекватной реализации бизнес-логики (включая тестирование, отладку и последующее сопровождение) снизилась минимум на порядок.

В обсуждаемой ситуации у нас есть выбор. Можно писать DLL ровно так же, как обычный Delphi-код без DLL. Коротко и ёмко. А можно непонятно зачем повесить на себя дикий геморрой, в котором "обязательно перехватывать исключения", "использовать коды возврата" и прочие ужас-ужас-ужас. И остаётся только один вопрос - зачем? В тех редких случаях, когда на этот вопрос есть действительно разумный ответ - ok, придётся мучиться как в прошлом веке. Но в 90% случаев это просто идиотизм архитектора, поскольку для этого нет ну совершенно никаких объективных причин.

Я пока так и не понял, что "исключительно добродетельного" в отсутствии практики передачи исключений из А в Б. Если такое желание натыкается на нерешаемые технические проблемы... ну, очень печально, но эпитет "добродетельно" меня озадачил.

Я не понимаю, о каком сценарии ты говоришь. Ну вот давай предположим, что в программе делается



Ну или аналогичное на любом другом ЯП. Внимание, вопрос. Что такого должно произойти внутри MyProcedure, чтобы при отловленных в ней исключениях всё было хорошо, а при неотловленных - софтина упала?

Ну и? Я не понимаю, каким образом от "открытия несуществующего файла" дойдёт до "софтина упала". Можно конкретно?


При связке Delphi+Delphi нет никакой границы и никаких заморочек. Кроме тех, которые люди зачем-то делают сами себе без причины на пустом месте.