softwarer...
Эдак Вы и в самом структурном цикле найдёте goto.
неужели есть сомнения в его там наличии? :)
softwarerПожму плечами. finally - наиболее очевидно необходимая вещь во всех исключениях. Если Вы хоть раз явно открывали курсор, странно не ощущать потребности в ней.
Пожму плечами. Finally - в части обязательной достижимости - синтаксический сахар,
"Играет" он только сохранением контекста возникшего в try неконтролируемого исключения.
Что с какой-то долей приближения тоже имитируется при необходимости.
Зачем придумали try-with-resources, если finally и без него великолепен?
И почему их теперь два - try? Как понять где resources, а где нет.
Вот выделенный массив в памяти - это не resources, а манипулятор файлом - resources.
Потому что ресурс под названием массив полностью управляется машиной времени выполнения. Его она сама освободит (когда-нибудь) без участия программиста.
А манипулятор файла - ресурс, запрашиваемый из внешнего, по отношению к runtime, мира.
Для pl/slq курсорная переменная, объявленная и открытая в блоке - локально управляемый ресурс, аналогично памяти в системах со сбором мусора.
Машина выполнения pl/sql гарантирует освобождение этого ресурса если не сразу по выходу курсорной переменной из области видимости, то по завершению вызова. И обычно гораздо раньше, чем проснется сборщик мусора в java.
Закрывать явно локально открытые курсоры - гораздо ближе к благим пожеланиям и правилам хорошего тона, чем к мечтам о finally.
softwarerБлок when others при всём желании не сможет работать как finally (ну разве что если возбуждать исключение специально чтобы в него попасть).
значит, все-таки может. Хотя я на этом в детальной точности не настаиваю.
Речь идет о "замыкании", гарантии завершения одного блока в целях 100% попадания в следующий. В частном случае следующим может быть сам раздел when others.
softwarerЧто же до правила - оно имхо максимально неудачно и может быть понято только если в качестве клиента выступает какое-нибудь древнее убожество, которое не умеет работать с исключениями. Но это тема скорее для форума Oracle.
...
Мне кажется, что "убожество" здесь ключевое слово.
В том смысле, что все не соответствующее "моей" модели восприятия мира является убожеством.
Мне вот может представляться убожеством, что где-то еще есть
клиенты , эксплуатирующие Oracle 9i.
Раз клиенты, значит эксплуатируют 9i, оплачивая при этом Sustaining Support, и не имея технической возможности замены версии.
Верю я в это или нет (верю) - не имеет "архитектурного" значения.
В смысле заголовка, заявленного в топике имеет значение другое - где и как проходит граница того, что вы называете разрабатываемой системой или ее ядром и внешнего по отношению к ней мира.
С максимально ясным и простым обозначением этих границ, не требующим расширенных навыков для опознавания стоящих по границе плакатов.
Та тропинка, которая привела меня к моей оглобле, в целом двигалась из точки зрения, считающей, что клиент - внешний по отношению к "системе" потребитель.
К степени убожества которого я, если смогу, не буду предъявлять специальных требований,
а если не смогу, то буду искать способ их минимизации.
Думаю, что вы попутали. Если клиент - автомобиль, то я не предполагаю наличие или отсутствие у него оглоблей.
Я предлагаю ему трос, уцепившись за который он сможет вытащить интересующую его информацию из внешней по отношению к нему, клиенту, системы.
О том - открываются курсоры и как закрываются - в нормальной истории ему знать не положено, предположительно совсем.
Это в предположении, что слой доступа к данным и взаимодействия с сервером он не рожает сам, а берет любой готовый, с любым крюком, пригодным к цеплянию за мой трос.
Хотя, если убрать оглобли и убожество, все действительно сведется к техническим особенностям, связанным с обработкой исключений "убогими клиентами" тоже.
Как у телеги две оглобли, так и у меня есть еще одно, второе "правило большого пальца"
по вопросу взаимодействия с убогими клиентами.
Но от темы исключений/goto оно еще дальше, так что пусть ждет следующих встреч.
