raboof commented on PR #432: URL: https://github.com/apache/commons-cli/pull/432#issuecomment-5043224416
> The sane way to consume a `Class`-typed option is parse first, validate, then use: (...) > The validation point goes back to the caller, where it belongs. You keep stating that as fact, but you don't really back that up with motivation. The advantages of doing the initialization early (the current behavior) are: * predictability: when there's something wrong it fails on startup, rather than later down the line where the code path could be dependent on other options, circumstances and timing * problem detection: when you introduce a problem in a static initializer, you immediately notice that problem, instead of only noticing it when you test the specific code path that touches that option * consistency: aborting before doing any work is less likely to leave the system in an inconsistent state compared to starting processing and only crashing when the problematic class is touched. The advantages of doing the initialization lazily (this PR) are: * performance: potentially faster startup, especially in invocations where static initializers are heavy and the relevant classes/options are not actually used * resilience: in situations where one class is causing trouble, you can still use the tool as long as you avoid the option associated with that class. * error handling: as you mention, an opportunity for the application to add error handling for options that are known to be potentially problematic I think I like the these advantages, but it's not _obvious_ that it's better, right? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
