InterruptedException, API дизайн и неплотные абстракции

Question

Хорошо решено, что InterruptedException вообще не следует проглатывать ; это запрос о том, что поток очищается и завершает свою работу.

Как должен дизайн API данной абстракции I обрабатывать InterruptedException, если подмножество его реализаций может выдать InterruptedException?

Более конкретно, представьте Datasource с реализациями InMemoryDatasource и NetworkDatasource. Последний включает блокирующий вызов по сети и, таким образом, может выдать InterruptedException. Это означает, что InterruptedException должен быть объявлен на интерфейсе Datasource.

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

Но это заставляет задуматься о другом - почему бы нам не увидеть, что more InterruptedException s объявляется в API?

Например:

• API JDB C не объявляет его, даже если он выполняет блокировку вызовов.
• Драйвер PostgreSQL JDB C проглатывает такие исключения и сбрасывает их как SQLException s. .
• Похоже, что драйвер MongoDB помещает его в RuntimeException.
• SDK AWS не выбрасывает его (но, по крайней мере, устанавливает прерванный flag).

Кажется, general не отбрасывает InterruptedException в API.

Как дизайнеру API, как лучше поступить с InterruptedException?