Нее, я как раз про то, что маловато многословности. Я прямо проникся дублированием методов в API, так, чтобы в API было 2 метода. Вот пример: https://github.com/apache/calcite/blob/77bb696d020bea4467151109ffed4ced53ff0c2d/core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java#L354-L364 private <T extends SqlValidatorNamespace> T getNamespace(SqlNode node) { //noinspection unchecked return (T) requireNonNull( getNamespaceOrNull(node), () -> "Namespace is not found for " + node); } @SuppressWarnings("unchecked") private <T extends SqlValidatorNamespace> @Nullable T getNamespaceOrNull(SqlNode node) { return (@Nullable T) validator().getNamespace(node); } Если кто-то вызывает getNamespace(…), а оно не найдётся, то эта штука упадёт, и не просто упадёт, а скажет «что именно пытались найти» (оно упадёт круче, чем jep 358 helpful nullpointerexception) Если же вызываающему не важно найдётся или нет, то он вызывает getNamespaceOrNull и при этом оно не падает. Optional тут был бы лишней концепцией. Я не говорю, что Optional вообще всегда лишняя тема. Я про то, что есть немало случаев, когда 2 метода в API проще, полезнее, безопаснее и удобнее, чем один, который возвращает Optional.
Я посмотрел на шарповые (да-да-да) каноны и теперь делаю getX(): T | null tryGetX(): Optional<T>
А как по шарповым канонам сделать firstNotNullOfOrNull ? (см https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/first-not-null-of-or-null.html )
linq FirstOrDefault, если я правильно понял
Обсуждают сегодня