Java: имеет ли смысл иметь универсальный атрибут throw?

Question

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

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

Возможно ли уже что-то подобное?Если да, то почему он еще не используется библиотекой Javas?

Если это пока невозможно, почему бы и нет?Не было бы сложно включить это в язык.И это сделало бы некоторые вещи более чистыми (см. Выше).

---

Один пример:

Я только что наткнулся на то, что Comparator.compare не может выдать исключение (см. здесь для смежного вопроса) и Collections.sort (или другие функции, использующие Comparator) также нет.

Для меня было бы гораздо больше смысла, если бы исключения, которые Comparator.compare может выдать,быть универсальным и Collections.sort будет бросать точно так же.Это решило бы мою проблему здесь гораздо более естественным и чистым способом.

Answer 1

Я не вижу какой-либо разумной причины, по которой упорядочивание объектов должно вызывать исключение. Я бы просто возвратил -1, если порядок «не указан», чтобы он попал в топ.

Answer 2

Я думаю, что генерирование исключения компаратором нарушает принцип единственной ответственности , единственная задача метода compare() - это взять два значения и вернуть результат сравнения, тогда как достоверность объектов должна быть проверена ранее.в звонилке.

Answer 3

Никто на самом деле не дал ответа (большинство ответов касались только моего примера, почему в этом случае это может быть нехорошо), поэтому здесь я пытаюсь ответить на него сам:

Нет, пока это невозможно.

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

Answer 4

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

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

Answer 5

Не имеет смысла усложнять подобный API для каждой отдельной реализации и каждого отдельного фрагмента кода, который использует Comparator s, так что отдельные случаи, которые хотят выдать проверенное исключение, могут выбрасывать их, а не переноситьв RuntimeException.Я также думаю, что вы ошибаетесь, говоря о субъективных вещах, таких как «естественный» или «чистый».Лично я не думаю, что было бы чисто использовать <Foo, RuntimeException> в качестве сигнатуры типа для 99,9% всех Comparator s.