Как реализация Итератора должна иметь дело с контролируемыми исключительными ситуациями?

Я переношу java.sql. RecordSet в java.util. Итератор. Мой вопрос, что я должен сделать в случае, если какой-либо recordset метод бросает SQLException?

java.util. Итератор javadoc объясняет, какие исключения добавить различные ситуации (т.е. NoSuchElementException в случае, если Вы звоните затем () вне последнего элемента),

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

Просто добавление SQLException затем () и hasNext () не возможно, потому что это является несовместимым с интерфейсом Iterator.

Вот мой текущий (упрощенный) код:

public class MyRecordIterator implements Iterator
{
    private final ResultSet rs;

    public MyRecordIterator() throws SQLException
    {
        rs = getConnection().createStatement().executeQuery(
                "SELECT * FROM table");         
    }

    @Override
    public boolean hasNext()
    {
        try
        {
            return !rs.isAfterLast();
        }
        catch (SQLException e)
        {
            // ignore, hasNext() can't throw SQLException
        }
    }

    @Override
    public Record next()
    {
        try
        {
            if (rs.isAfterLast()) throw new NoSuchElementException();
            rs.next();
            Record result = new Record (rs.getString("column 1"), rs.getString("column 2")));
            return result;
        }
        catch (SQLException e)
        {
            // ignore, next() can't throw SQLException
        }
    }

    @Override
    public void remove()
    {
        throw new UnsupportedOperationException("Iterator is read-only");
    }
}

8
задан amarillion 27 February 2010 в 10:43
поделиться

1 ответ

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

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

например.

    @Override
    public boolean hasNext() {
      try {
        return !rs.isAfterLast();
      } catch (SQLException e) {
        throw new MyApplicationException("There was an error", e);
      }
    }

Обновление: чтобы начать поиск дополнительной информации, попробуйте погуглить "отмечен и не отмечен java sqlexception". Довольно подробное обсуждение обработки проверенных и непроверенных исключений в 'Best Practices for Exception Handling' на onjava.com и обсуждение некоторых различных подходов на IBM Developerworks .

11
ответ дан 5 December 2019 в 15:22
поделиться
Другие вопросы по тегам:

Похожие вопросы: