Exception was discarded, but it shouldn't

[okou19900722]

when I invoke from client but not connection, it's will get connection and do action in the callback. if the action throw a exception, and no exception handler of Context was setting .The exception will discard.

also see https://github.com/vert-x3/vertx-mysql-postgresql-client/issues/116

https://github.com/vert-x3/vertx-mysql-postgresql-client/blob/12a6e6f89478998a6075b34b7b0e8272dc2e6a14/vertx-mysql-postgresql-client-jasync/src/main/java/io/vertx/ext/asyncsql/impl/pool/AsyncConnectionPool.java#L115-L129

client.queryWithParams("select * from player where id=?",JsonArray().add(1).add(2)) {
    // callback never execute
}

client.getConnection() {
    try {
        it.queryWithParams("select * from player where id=?",JsonArray().add(1).add(2)) {
            // do something
        }
    } catch(e : Throwable) {
        //got the exception
    }
}

[oshai]

I think this is by design. You should add exceptions handler.

[okou19900722]

Can not catch the Exception with client.queryWithParams or other methods

[oshai]

getConnection() requires a handler of AsyncResult. You can check result.falied() see here: https://vertx.io/docs/apidocs/io/vertx/core/AsyncResult.html

[okou19900722]

so I can't use client.queryWithParams, is it?

[oshai]

you can use that, just have to make sure there is no exception before. If there is an exception in the connection, then you can't.

[okou19900722]

I don't agree with this design, no one can guarantee that the code will never throw an exception. So I think the callback of client.queryWithParams should be guaranteed to handle exceptions. The design of vertx-jdbc-client is very good

[oshai]

ok. I am not the owner of this repo, nor the designer. However, I think changing it now will not be compatible with previous versions.

[okou19900722]

I think you should not understand what I mean, you can execute this code, the callback will never be called

client.queryWithParams("select * from player where id=?",JsonArray().add(1).add(2)) {
    // callback never execute
}

[okou19900722]

I don't think this is the wrong design, I think this is a bug.