The validate modifier should also catch all exceptions.

[Jadarma]

The documentation on handling errors says:

convert and the other parameter transformations will wrap exceptions thrown inside them in a UsageError, so if you define a custom transformation, you don’t have to worry about an exception escaping to the user.

Since validate is not technically a transformation, the documentation does not lie, but the usage is unintuitive.
I foolishly assumed the require function is the same as the Kotlin stdlib, however it is an overload in the context of the OptionValidator.
I have some type that requires some more complex validator that is too big to fit nicely in the option declaration site, so it is extracted in a separate function:

val foo by option("--foo").validate { customValidationLogic(it) }

However, when validation fails here, since the custom logic does not throw BadParameterValue, it crashes the program assuming it's a programming error.

As a workaround for the time being, one must either do validation logic inside a convert lambda, or manually wrap exceptions, I defined my own util for this:

inline fun <AllT, EachT, ValueT> OptionWithValues<AllT, EachT, ValueT>.validateCatching(
    crossinline validator: OptionValidator<AllT & Any>,
): OptionDelegate<AllT> = copy(
    transformValue,
    transformEach,
    transformAll,
    validator = {
        if (it != null) runCatching { validator(it) }.getOrElse { cause ->
            throw BadParameterValue(cause.message.orEmpty(), option)
        }
    },
)

I believe the .validate {} lambda should match the behavior of the other transformers, to make it easier to use validation logic from functions that might come from external libraries, for example.

[joffrey-bion]

IMO validation should be controlled. Not all exceptions are validation errors, so you should be careful about what you throw where.

runCatching should almost never be used, as you're catching way more that you should. Is an OutOfMemoryError really a validation error in your opinion? How about ThreadDeath, or NoSuchMethodError, or NoClassDefFoundError, or ClassNotFoundException? How about CancellationException?

If you extract customValidationLogic, give it the same scope/context as the lambda you use it in, and you'll get the same convenient overloads. No need for a catch-all.

Also, the cause.message is not enough to identify a problem. A lot of Java exceptions rely on the exception name for context, and the message just adds on top but cannot stand on its own. For instance, FileNotFoundException just provides the path as message.

[Jadarma]

I understand the intricacies of various exceptions in general, however in this case I was just arguing for consistency between option transformers, comparing the behavior of validate to the one of convert. Conceptually they do the same thing: assert some logic over a T, except convert maps it to something else, while validate doesn't.

If you look at the convert one, it does the same thing as my temp workaround snippet, a try-catch wrapping in a usage error with the message or none. (In my case I knew I wouldn't catch a UsageError because the validation logic comes from myself, so I didn't check for it.)

Whether the failsafe try/catch keeps the message of the inner exception is another discussion, it may as well be a hardcoded "Option --foo is invalid", but I expect it to be there, like convert has it.