Сообщение Re[5]: Result objects - все-таки победили Exceptions? от 07.01.2025 12:09
Изменено 07.01.2025 12:10 vsb
Re[5]: Result objects - все-таки победили Exceptions?
Здравствуйте, Shmj, Вы писали:
S>Просто люди не проработали в голове концепцию и как бы боятся исключений. Привыкли терять контроль над кодом. У меня каждый метод КАЖДЫЙ — я 100% знаю не только параметры, но и все возможные исключения, которые он может выбросить. Т.е. 100% контроль кода. А люди привыкли к исключениям относиться как к магии. Как бы какая-то неприятность, которой быть не должно.
Во-первых, если говорить про Java, каждый метод может бросать StackOverflowError при вызове.
Во-вторых 99% методов могут бросать OutOfMemoryError при использовании new или вызове других методов, использующих new.
Это просто штатно, альтернатива разве что ронять JVM вместо выброса таких исключений, но это уже совсем глупо.
Точно так же 99% методов могут бросать разные другие исключения. К примеру вызываем метод, его байткод не загружен в JVM. Грузим байткод, диск сломался и бросил IOException при попытке чтения JAR файла. Кидается IOException обёрнутый в какой-то Error. Это всё теоретически возможно.
Т.е. концепция полного отказа от непроверяемых исключений не выдерживает никакой критики. Всегда будет множество ошибок, которые в теории могут возникать, но которые 100% неразумно включать в контракт функции.
S>Просто люди не проработали в голове концепцию и как бы боятся исключений. Привыкли терять контроль над кодом. У меня каждый метод КАЖДЫЙ — я 100% знаю не только параметры, но и все возможные исключения, которые он может выбросить. Т.е. 100% контроль кода. А люди привыкли к исключениям относиться как к магии. Как бы какая-то неприятность, которой быть не должно.
Во-первых, если говорить про Java, каждый метод может бросать StackOverflowError при вызове.
Во-вторых 99% методов могут бросать OutOfMemoryError при использовании new или вызове других методов, использующих new.
Это просто штатно, альтернатива разве что ронять JVM вместо выброса таких исключений, но это уже совсем глупо.
Точно так же 99% методов могут бросать разные другие исключения. К примеру вызываем метод, его байткод не загружен в JVM. Грузим байткод, диск сломался и бросил IOException при попытке чтения JAR файла. Кидается IOException обёрнутый в какой-то Error. Это всё теоретически возможно.
Т.е. концепция полного отказа от непроверяемых исключений не выдерживает никакой критики. Всегда будет множество ошибок, которые в теории могут возникать, но которые 100% неразумно включать в контракт функции.
Re[5]: Result objects - все-таки победили Exceptions?
Здравствуйте, Shmj, Вы писали:
S>Просто люди не проработали в голове концепцию и как бы боятся исключений. Привыкли терять контроль над кодом. У меня каждый метод КАЖДЫЙ — я 100% знаю не только параметры, но и все возможные исключения, которые он может выбросить. Т.е. 100% контроль кода. А люди привыкли к исключениям относиться как к магии. Как бы какая-то неприятность, которой быть не должно.
Во-первых, если говорить про Java, каждый метод может бросать StackOverflowError при вызове.
Во-вторых 99% методов могут бросать OutOfMemoryError при использовании new или вызове других методов, использующих new.
Это просто штатно, альтернатива разве что ронять JVM вместо выброса таких исключений, но это уже совсем глупо.
Точно так же 99% методов могут бросать разные другие исключения. К примеру вызываем метод, его байткод не загружен в JVM. Грузим байткод, диск сломался и бросил IOException при попытке чтения JAR файла. Кидается IOException обёрнутый в какой-то Error. Это всё теоретически возможно.
Мы логгируем что-то в stdout и может броситься ошибка.
Т.е. концепция полного отказа от непроверяемых исключений не выдерживает никакой критики. Всегда будет множество ошибок, которые в теории могут возникать, но которые 100% неразумно включать в контракт функции.
S>Просто люди не проработали в голове концепцию и как бы боятся исключений. Привыкли терять контроль над кодом. У меня каждый метод КАЖДЫЙ — я 100% знаю не только параметры, но и все возможные исключения, которые он может выбросить. Т.е. 100% контроль кода. А люди привыкли к исключениям относиться как к магии. Как бы какая-то неприятность, которой быть не должно.
Во-первых, если говорить про Java, каждый метод может бросать StackOverflowError при вызове.
Во-вторых 99% методов могут бросать OutOfMemoryError при использовании new или вызове других методов, использующих new.
Это просто штатно, альтернатива разве что ронять JVM вместо выброса таких исключений, но это уже совсем глупо.
Точно так же 99% методов могут бросать разные другие исключения. К примеру вызываем метод, его байткод не загружен в JVM. Грузим байткод, диск сломался и бросил IOException при попытке чтения JAR файла. Кидается IOException обёрнутый в какой-то Error. Это всё теоретически возможно.
Мы логгируем что-то в stdout и может броситься ошибка.
Т.е. концепция полного отказа от непроверяемых исключений не выдерживает никакой критики. Всегда будет множество ошибок, которые в теории могут возникать, но которые 100% неразумно включать в контракт функции.