org.springframework.jdbc.core

Interface RowCallbackHandler

  • All Known Implementing Classes:
    RowCountCallbackHandler
    Functional Interface:
    This is a functional interface and can therefore be used as the assignment target for a lambda expression or method reference.


    @FunctionalInterface
    public interface RowCallbackHandler
    An interface used by JdbcTemplate for processing rows of a ResultSet on a per-row basis. Implementations of this interface perform the actual work of processing each row but don't need to worry about exception handling. SQLExceptions will be caught and handled by the calling JdbcTemplate.

    In contrast to a ResultSetExtractor, a RowCallbackHandler object is typically stateful: It keeps the result state within the object, to be available for later inspection. See RowCountCallbackHandler for a usage example.

    Consider using a RowMapper instead if you need to map exactly one result object per row, assembling them into a List.

    Author:
    Rod Johnson, Juergen Hoeller
    See Also:
    JdbcTemplate, RowMapper, ResultSetExtractor, RowCountCallbackHandler
    • Method Summary

      All Methods Instance Methods Abstract Methods 
      Modifier and Type Method and Description
      void processRow(java.sql.ResultSet rs)
      Implementations must implement this method to process each row of data in the ResultSet.
    • Method Detail

      • processRow

        void processRow(java.sql.ResultSet rs)
                 throws java.sql.SQLException
        Implementations must implement this method to process each row of data in the ResultSet. This method should not call next() on the ResultSet; it is only supposed to extract values of the current row.

        Exactly what the implementation chooses to do is up to it: A trivial implementation might simply count rows, while another implementation might build an XML document.

        Parameters:
        rs - the ResultSet to process (pre-initialized for the current row)
        Throws:
        java.sql.SQLException - if a SQLException is encountered getting column values (that is, there's no need to catch SQLException)