使用R2DBC时检测意外阻断的电话

不久前，jOOQ为jOOQ的API添加了org.jetbrains:annotations依赖，以便为返回类型标注nullability信息。例如，整个DSL是不可归零的:

public interface SelectWhereStep<R extends Record>
extends SelectConnectByStep<R> {

    @NotNull @CheckReturnValue
    @Support
    SelectConditionStep<R> where(Condition condition);

    // ...
}

特别是给kotlin用户提供这种保证是有意义的，因为他们可以摆脱一些更复杂的类型，涉及到像Select!<Record!> ，现在至少变成了Select<Record!> 。还要注意@CheckReturnValue注解，IntelliJ将其用于一些内省。

其他情况则更明显，比如:

public interface ResultQuery<R extends Record> 
extends Fields, Query, Iterable<R>, Publisher<R> {

    @Nullable
    @Blocking
    R fetchOne() throws TooManyRowsException;

    @NotNull
    @Blocking
    R fetchSingle() throws NoDataFoundException, TooManyRowsException;

    // ...
}

这两种类型的获取方法之间的区别是：fetchOne() 希望得到0-1条结果记录，而fetchSingle() 希望得到正好1条记录。否则两者都会抛出异常，但只有后者能保证记录值不为零。

但是等等，这个@Blocking注解是什么？

在jOOQ 3.17中，我们为所有在JDBC之上执行查询的jOOQ API添加了org.jetbrains.annotations.Blocking 注解。这完全不影响基于JDBC的jOOQ查询的用户，但是如果你使用R2DBC进行jOOQ的反应式查询，你可能会不小心调用jOOQ的许多许多阻塞式执行方法中的一个。

现在不会了!IntelliJ现在会抱怨这样的调用是不合适的:

至少在你启用自省的时候。

这取决于你想让这成为一个警告还是一个错误，但至少，你会注意到你即将做错的事情。