stepplerus1. JAVA - не монастырь, JAVA - инструмент. Нельзя предъявлять претензии к инструменту? С каких это пор?"Знай, что хаешь" (ц) dz. Сказано было про OS/2, но актуально до сих пор.2. Я покручу SecurityManager."В некоторых случаях не помогает и чтение газет".
Диспетчер безопасности - совершенно отдельная категория исключений. Прикладная, а не системная.3. В операционных системах дают себе труд создать и описать стопитсот ошибок. Не вижу никаких причин не сделать это в JAVA. Кроме как "нам это сдавать ко второму явнваря, а еще код не весь проверен".Покажите мне этих титанов. Которые свели воедино список ошибок винды, полуоси, солярок, фрей и разномастных линуксов. На железках от сотовых до персоналок.
Родина должна знать своих героев.
Миникомпьютеры, мэйнфрэймы и их операционки, так и быть, добавлять не станем.Почему не сделать все одинаково?"Делай настолько просто, насколько это возможно, но не проще".5. Не должен я "нырять в потроха". Вынужден, да. Но не должен.Ну тогда - спасибо, я уже насмотрелся на результаты такого профессионализма.

stepplerusСначала есть момент выбора - на чем реализовывать.Это задача архитектора проекта.
В нормальной ситуации учитывают, что короткий путь - известный путь.Можете считать, что я узнаю степень ее "промышленности".Пока демонстрируете, что "узкий специалист подобен флюсу, ибо полнота его односторонняя".
Не надо начинать ответственный проект "на чужом поле".

stepplerusИ где та оспополам?Где бы она ни была - JRE/JDK для неё существуют. До 1.3.1 - IBM, 1.4 - GoldenCode, далее - "одинизация".А DZ (если это тот, кого я знал), тот еще охальник.Возможно, но мысль его - абсолютно здравая, а формулировка - чёткая.Я почитаю про SecurityManager подробно.Вот задлянафига? Апплет пишите? Или заказчик потребовал, чтобы приложение было "поражено в правах"?Не надо сводить вместе ошибки разных операционных систем. Достаточно вернуть то, что возвращает операционная система.Мопвашуять ...
Вот работает у нас две системы одного разработчика. Одна под виндой, другая под линуксом. Ту, которая работает под виндой можно взять и запустить под линуксом. Единственное изменение - стартовые скрипты.
А с вашим подходом ещё и коды ошибок станут другие. Внезапно.
Нафига такое счастье, особенно с учётом того, что на момент возникновения ошибки никто и ничего оперативно исправить не может. Ни приложение, ни даже администратор. Я, лично, ни в DOS, ни в UNIX (разных), ни в WINDOWS, ни в Novell не имел проблем с получением кода ошибки от файловой системы. Ни на одном средстве разработки."Проблема не в том, что человек смертен, а в том, что иногда он внезапно смертен".Пока с JAVA не познакомился.Это и в ява не проблема. Но возврат boolean вместо int - это фича, а не бага. Вполне разумное решение.Вот майнфреймах я только математическими вычислениями занимался, ничего не могу сказать про их файловые системы.Там и файловых систем может не быть. Зато может быть эмуляция ленты или диска. Или скажем "родная" файловая система OS/400 - отличается от posix-like. Хотя и умеет их эмулировать.

stepplerus"Промышленность" - это, в том числе, и беспроблемность.Это иллюзия.Типа, "сел и поехал". Без доработки напильником.А это - мракетинг. Тоже иллюзия, но хуже.А если нужен напильник, то это уже, скорее, "на коленке сделанная".Напильник нужен всегда. Важно (без нужды) не точить то, что уже выпилено.
Программирование, в этом отношении, уникально - только здесь можно изготовить переходник с болта М9 на гайку М6.

Petro123эх, а хорошо бы что нибудь такого промышленного))

Стек-трейсы рабочей системы давно смотрели?
Работает, что характерно, без участия программиста.

stepplerusЭто будет уже моей проблемой, правда?Нет.
Я вспомнил про стек-трейсы рабочей системы. System-specific ошибки там есть.

P.S. А проблему будет решать системный администратор :)

Petro123У той, что выше, прикладной код и его ошибку надо дать СРАЗУ пользователю или девочке рядом из техподдержки.
А файл на шаре заблокирован с другой проги на соседнем этаже.Зная уровень техподдержки, могу обоснованно утверждать, что "не могу удалить файл" и "Отказано в доступе" для них совершенно эквивалентны.
Поэтому в данном конкретном случае (удаление файла) возврат true/false - вполне обоснован.
Если возникнет ошибка ввода/вывода, будет выброшено java.io.IOException и там, среди прочего, будет и "нативная причина".

P.S. Если кто-то думает, что типичная техподдержка умеет/хочет читать стек-трейсы - он сильно ошибается.

Petro123вот и выходит, что есть СЕРВЕРНАЯ система, где ошибки на уровне оси заранее исключаются (выводятся в логи)."Шматрица":

"Наш" клиент - выдаёт исключение пользователю. А сервер приложений - пишет в лог.
Так-шта-а - как закажете.

svenomFile.delete() не бросает IOException.Я в курсе.
Можно спорить насколько "архитектурно правильно" размещать delete в jav.io.File, но я бы хотел увидеть код, который может исправить ошибку удаления файла, располагая кодом системной ошибки.

stepplerusА переходники и из железа есть.С болта М9 на гайку М6? А ведь исходный пример - гораздо гораздее.

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

svenomЭто заморочки-из-бочки на пустом месте.Ну вот человек привык анализировать код и на основании анализа - принимать решения.
Анализировать ситуацию и принимать решения - он пока(?) не додумался.
Но Пастернака уже осуждает.