Declaring runtime exceptions

What is the guideline for methods declaring runtime exceptions?

Let's say I call a 3rd party routine that throws SQLException. Is it permissible/standard/acceptable for that routine to be able to throw RuntimeExceptions without declaring that it does so?

As always, I am surprised by the confusion my questions cause :-D This is probably because I am confused.

In the following, the callable is a lambda that issues a commit, and this throws SQLException. callable.call throws Exception.

private doThis(Callable<T> callable) throws SQLException {
    try {
        return callable.call();
    } catch (SQLException e) {
        // do stuff
        throw e;
    } catch (Exception e) {
        break; // Eats any exception from call() which makes me scream internally.
    }
}

What I surmise from this is that the coder wanted doThis to throw a SQLException. However, the nature of using the Callable meant that the routine had to throw an Exception unless the coder did something. So he caught Exception and swallowed it. But Exception is the parent is RuntimeException, so we're eating those too.

What am I to do? Making doThis throw Exception seems clumsy and random. Wrapping any exception being thrown in a RuntimeException and raising that preserves the coder's intent but seems suspect.

EDIT -

ok, I have learned, thank you. Now the question is, what to do about it. Clearly, eating the exception is a bad idea. Diluting the SQLException as declared seems not great.

How does the collective wisdom of SO feel about wrapping the Exception in a RuntimeException?

    ...
    } catch (Exception e) {
        throw new RuntimeException(e);
    }