Существует ли конкретное соглашение о присвоении имен для методов Java, которые выдают исключения?

Не делайте этого.

Это похоже на вопрос: «Существует ли соглашение об именах для методов, которые принимают две строки в качестве параметров».

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

Обновление: Похоже, вы намерены создать методы, которые проверяют, истинно ли определенное условие, но вы не хотите возвращать только false, но генерировать исключение, если условие не выполняется, чтобы вы также могли передать сообщение с объяснением (в исключении). Я думаю, что префикс «assert» или «sure» имеет смысл:

 // instead of
 if (! isAuthenticated())
    throw new NotAuthenticatedException("not sure why at this point...");

 // you do
 assertAuthentication();
 // which will throw NotAuthenticatedException("proper explanation") inside

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

Если вы нужно различать эти методы, я уверен, что вы можете сделать это в именовании без использования суффикса или чего-то еще, что (как указывали другие) довольно ужасно.

Почему:

boolean authenticate(String username, String password);

и (скажем)

void authenticateEx(String username, String password) throws WhateverException;

, когда вы могли бы сделать его значимой частью имени, передав фактическое намерение:

void ensureCanAuthenticate(String username, String password);

// or

void assertValidCredentials(...);

// or

void authenticateOrDie(...);

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

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

Венгерская нотация для методов, генерирующих исключения? Quel horror!

Вы имеете в виду отмеченные или непроверенные исключения? Зачем вам это нужно?

Если подумать, вам придется добавить свое соглашение к каждому методу, потому что всегда есть вероятность ошибки, NPE или чего-то еще, что может пойти не так.

Предложения о «бросках» достаточно, если вы проверили исключения, и на Божьей зеленой земле нет хорошей цели для непроверенных исключений.

Не делайте этого. Пожалуйста.

Соглашения нет, и добавление ex усложнит чтение имени и уродливое для среднего программиста java.

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

Это не обязательно должно быть что-то уродливое, вроде того, что можно найти во многих программах c / c ++, где вы используете _name или mName для членов или iValue для целых чисел. Но в java тоже есть некоторые соглашения. Если метод возвращает целое число, перед ним стоит префикс is ... set, get и test - наиболее часто используемые примеры для этого. Все это задокументировано в заголовке метода с помощью аннотаций типа возвращаемого значения и т. Д. Но добавление одного слова к имени функции упрощает и ускоряет чтение и понимание.

Почему бы не использовать попробуйте дать программистам прочитать ваш код подсознательный намек на то, что этот метод может вызвать исключение. Как tryCopyFile вместо tryWriteFile.

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

Мне любопытно узнать, почему у вас возникает соблазн использовать такое соглашение об именах.

Я ничего не знаю о нем.

На мой взгляд, единственный раз, когда что-то это имеет смысл в случаях модульного тестирования (например, testFooExpectingException ()). Но вы говорите не об этом.

Время от времени вы будете сталкиваться с ситуацией, когда имеет смысл использовать имя метода, например getSafely () (возвращает значение по умолчанию в случае где фактическое значение недопустимо для кода, который не слишком заботится о реальных значениях и заполнителях) или его обратном getOrBlowUp () (для отказоустойчивого кода, где отсутствующее значение технически возможно, но указывает на ошибка в коде, который должен установить значение).

Но дело здесь не в том, что «метод 2 выдает исключение, а метод 1 - нет» - потому что, как упоминалось выше, любой код может вызывает исключение RuntimeException . Дело в том, что эти два метода имеют разную семантику обработки ошибок, специфичную для разных случаев использования, и , что « s то, что имена методов пытаются уловить.

Даже в этом случае код обычно был бы чище, если бы вы могли просто избежать того или иного поведения и вызвать метод get ()

Полезной параллелью здесь может быть различие между Венгерскими системами и Венгерскими приложениями в венгерской нотации. (См. Также эту статью о соглашениях о кодировании от Joel on Software.)

• Systems Hungarian просто сообщает вам тип переменной, поэтому целое число count становится iCount ]. Это наиболее распространенная форма венгерской нотации, и IMHO это (1) довольно бессмысленно с современной IDE и (2) потенциально обманчиво, если кто-то изменит объявление типа без переименования переменной.
• Apps Hungarian сообщает вам назначение переменной, поэтому целое число (или короткий, или порядковый идентификатор объекта, или что-то еще, кого это волнует?) индекс , представляющий строку данных, становится drIndex , а индекс представляет столбец аннотации становится acIndex . Это гораздо более полезно и с меньшей вероятностью вызовет проблемы.

Вызов вашего метода getEx () является системным венгерским.