(I didn't know that PostgresqlException -- terribl...

# arrow

[dave08]

(I didn't know that PostgresqlException -- terrible naming --- in R2dbc wasn't a Throwable... that's why catch didn't get it...) -- Maybe another little thing to include in the Intellij plugin? When to use each of the catch/recover variants...

[dave08]

I had to do:

try {
                    db.runQuery(QueryDsl.executeScript(getResourceAsText("/schema.sql")!!))
                } catch (t: R2dbcNonTransientException) {
                    val error = t.nonFatalOrThrow() as? PostgresqlException
                    logger.error { "Error importing schema: ${error?.errorDetails}"}
                }

Since PostgresqlException is just an interface... and only it has the errorDetails property 🙈

[simon.vergauwen]

PostgresqlException is an interface implemented by R2dbcNonTransientException? 🤯

Good idea, I think in a lot of cases catch can be replaced by try/catch. Everywhere where you catch a specific exception, except IllegalStateException.

[dave08]

static final class PostgresqlPermissionDeniedException extends R2dbcPermissionDeniedException implements PostgresqlException

public interface PostgresqlException {
    ErrorDetails getErrorDetails();
}

[dave08]

The R2dbcPermissionDeniedException extends public abstract class R2dbcException extends RuntimeException in the end... I'm not sure why that exception doesn't have those error details instead of making an interface out of it... 😵‍💫

[dave08]

, I think in a lot of cases catch can be replaced by try/catch.

So when would we use the catch variant that catches a specific throwable?

[dave08]

Will it just be deprecated in favour of try/catch?

[simon.vergauwen]

One of the biggest problem in Kotlin is catching CancellationException, and CancellationException extends IllegalStateException which is thrown by many functions. So catching IllegalStateException might accidentally result in catching, and recovering from a CancellationException. That's when you should be using catch.

Additionally, when you need to catch Throwable, well you need to protect from CancellationException and fatal JVM exceptions.

So in any of those cases you'd need catch, you might prefer to just use catch always to be consistent and avoid surprises. That's what many people do. I've personally gone back and forth, not sure if I have any preference but if I write public examples I prefer to avoid more new things all at once so I use try/catch when it makes sense, and it turns out I don't need to catch Throwable or IllegalStateException much. Mostly I am turning SDK, or Database, exceptions into typed errors where I need them.

A back-and-forth refactor action, with an analyses for preventing this mistake seems appropriate since it's more subjective and a plugin can help to easily refactor.