Как именовать два метода один из которых выбрасывает исключение?

Question

[vi0]

Есть два метода с одинаковой сингатурой, но второй может выбрасывать исключение.
Как бы вы именовали подобные методы?
Или может быть решаете вопрос по другому?

public Optional<Entity1> findById(String id) {
    return repository.findById(id);
}

public Entity1 findById(String id)  {
    return repository.findById(id).orElseThrow(
            () -> new UncheckedException1("error1")
    );
}

Answer 1

[Mercury13]

findById и requireById.
В данном случае.

Answer 2

[Mikhail]

Что у вас за кейс? Почему обязательно нужны оба метода?
Я бы оставил какой-то один.

Comments

[vi0]

- Для пустого Optional выше по стеку будет создаваться новый элемент
- Исключение прерывает расчет т.к. нет требуемого элемента

[Mikhail]

vi0, это все понятно. Непонятно зачем понадобились два метода, делающие одинаковую работу.
Не знаю, что у вас за нужда, но если бы мне такое попалось на код-ревью, я бы отправил на переделку

[vi0]

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

Answer 3

[Dmitry Roo]

0. Так оно у вас не соберется. Компилятор скажет "findById(String) is already defined in ..."
1. Исключение предполагает какой-то элемент неожиданности. Если вы хотите назвать метод "получитьАйДиИлиБроситьИсключение" предполагается, что это исключение должно быть уже как-то обработано, т.е. бросать вы должны проверяемое исключение, а проверяемые исключения (checked exeption) предполагают какую-то логику, а это уже все вместе вырастает в антипатерн "логики на эксепшенах".
2. Если у вас все-же метод бросает какое-то непроверяемое исключение (ну так вышло), то ничего о нем сообщать дополнительно не требуется (оно же непроверяемое!).
3. Буква S в слове SOLID означает Single Reponsibility. Никакой метод, кроме специально для этого предназначенного, не должен никак реагировать на исключения. Реагировать на исключения - это дополнительная обязанность. Если у вас, по какой-то досадной случайности появился чекд-эксепшен, самое лучшее, что вы с этим можете сделать - поставить над методом аннотацию ломбока @SneakyThrows

Comments

[vi0]

1. Не нужно обрабатывать

[vi0]

"получитьАйДиИлиБроситьИсключение"
я вот тоже вижу что то типа такого названия

[Dmitry Roo]

vi0, я думал будет понятно, что так делать не надо

[Dmitry Roo]

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

[vi0]

Dmitry Roo, я на питоне писал по русски

Answer 4

[Артём Дайнов]

1. На лицо перегрузка. Первый метод возвращает entity обернутый в Optional, а второй возвращает просто entity, с проверкой на исключение.
2. Их можно оставить как есть, а по возвращаемому типу понимать, что один из них вернет исключение.
3. В первом можно подтянуть метод .isPresent()
4. Второй метод я бы назвал findByIdAndException
5. id как string не самый лучший вариант. Помните о том, что String не изменяем и может привести к загруженности памяти.

Comments

[Mikhail]

В джаве считается, что у этих методов одинаковая сигнатура, т.к. тип возвращаемого значения в сигнатуру не входит.
И как уже написали, такой код компилятор не переварит.

[Артём Дайнов]

Mikhail, Да не переварит, но если он спрашивает, то каким-то образом он у него съел. Или человек просто от фонаря написал код тут.

[vi0]

Артём Дайнов, обратите внимание какой я вопрос задал в топике

Answer 5

[gsaw]

"find" как бы подразумевает, что можно и не найти, а "get" имхо звучит жёстче.
getById (Checked)
findById (Optional)

Answer 6

[Орхан Гасанлы]

Тут можно по-разному поступить. Вот, как это делаю я:

Способ 1: название методов get* & find*

User getUserById(Long id) {
	return userRepository.getReferenceById(id);
}

Optional<User> findUserById(Long id) {
	return userRepository.findById(id)
		.orElseThrow(() -> new NotFoundException());
}

Способ 2 - я вообще из сервисов не возвращаю Optional никогда. Ведь, по сути если вы будете этот слой сервиса использовать в другом сервисе, то скорее всего вам понадобится сама сущность, а не Optional, а если данной сущности нет, то какой смысл дальше его сеттить, а значит нужно выбросить исключение. Обратите внимание, что второй метод возвращает DTO

User findById(Long id) {
	return userRepository.findById(id)
			.orElseThrow(() -> new NotFoundException());
}

UserDTO findUserById(Long id) {
	return userMapper.toDTO(findById(Long id));
}

Способ 3: Если не хотите, чтобы исключение выбрасывалось например.
Допустим, у вас первый сервисный слой PostService вызывает второй AuthorService, чтобы выполнить findById и засеттить его значение к записи. Если вы выполните это на уровне сервисов, то исключение будет брошено. Но можно сделать это на уровне мапперов и в случае отсутствия записи засеттить null. Если память не изменяет, такое работает в MapStruct с NullValuePropertyMappingStrategy

Cпособ 4
Создаю 2 метода. Первый возвращает сущность или выбрасывает исключение, а второй возвращает сущность или нулл

Comments

[vi0]

тут пустое Optional никогда не вернется, будет исключение

Optional<User> findUserById(Long id) {
	return userRepository.findById(id)
		.orElseThrow(() -> new NotFoundException());
}