Какой смысл в типе OurCompanyRuntimeException в Java?

Question

В компании, где я сейчас нахожусь, в коде есть много мест, где создается исключение OurCompanyRuntimeException (где OurCompany - это фактическое название компании). Насколько я могу судить, это исключение описывается как «Исключение во время выполнения, выданное кодом, который мы написали здесь, в этой компании».

Я немного новичок в Java, но я думал, что типы исключений должны были отражать , что пошло не так, а не , чей код вызвал исключение. Например, IllegalArgumentException означает, что кто-то передал недопустимый аргумент чему-либо. У вас не будет SunIllegalArgumentException, если в коде, написанном Sun, передан недопустимый аргумент, а затем IBMIllegalArgumentException - это будет глупо и бессмысленно, верно? И если вы хотите знать, где было сгенерировано исключение, вы посмотрите на трассировку стека. Я понимаю, что хочу расширить RuntimeException (чтобы у вас не было столько попыток / перехватов или «бросков»), но почему бы не создать подклассы, объясняющие, что произошло, а не код какой компании это произошло?

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

Answer 1

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

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

Answer 2

Да, я тоже с этим сталкивался, но для меня это тоже не имело смысла. Я предположил, что компании написали это исключение очень рано после принятия Java, не получив правильного представления о том, как на самом деле работает создание и обработка исключений (как уже сказал Ник ... старшим программистом, никто не осмеливался сомневаться). Если компания чувствует необходимость создания своего собственного класса исключений (например, для отдельных частей журналирования), это исключение никогда не должно создаваться напрямую (делая его абстрактным). Вместо этого я бы получил конкретную проблему, описывающую исключения, или просто следовал бы идее Spring Framework для обработки / выброса исключений.

Answer 3

Помогает при чтении трасс стека, это точно. То есть при сканировании множества строк «вызвано» это помогает увидеть, что это произошло во что-то, брошенном вами, а не во внутреннем, скажем, контейнере.

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

Answer 4

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

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

Answer 5

Было бы очень разумно иметь это как базовый класс для определенных исключений. Вы бросили конкретное исключение и поймали базовый класс.

Также это может позволить нести причину (РЕАЛЬНОЕ исключение) плюс дополнительную информацию. Это может быть очень удобно для создания диагностического вывода для ведения журнала.

Answer 6

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

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

Answer 7

Это плохая концепция. Исключения должны быть специфическими для варианта использования.

Хорошо, если компания действительно производит много неисправного кода / продуктов, они могут использовать этот тип исключения в качестве рекламы;)

Answer 8

Было бы неплохо иметь общий класс исключений для всей компании, как вы описываете, от которого наследуются более конкретные случаи исключений. В одном ответе уже упоминалась возможность специально перехватывать исключения из внутреннего кода и игнорировать / проходить через те из основного кода Java или кода сторонней библиотеки. Ключевым моментом здесь является то, что более конкретные исключения должны наследоваться от этого. Создание общего исключения с именем компании будет требоваться редко и почти никогда не рекомендуется.