Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make mainBody behavior the default when parsing args #65

Closed
holgerbrandl opened this issue Sep 7, 2018 · 3 comments
Closed

Make mainBody behavior the default when parsing args #65

holgerbrandl opened this issue Sep 7, 2018 · 3 comments

Comments

@holgerbrandl
Copy link

It took me quite a while (and frustration) to realize that my naive way of setting up a parser with

val args = ArgParser(args).parseInto(::MyArgs) 

wont give any help by default unless I wrap it with

val args = mainBody { ArgParser(args).parseInto(::MyArgs) }

Why can't parseInto catch the exception by default and print the help (similar to how mainBody works). Requiring a lambda here seems too much. A boolean parameter such as catchEx or similar (defaulting to to true) for parseInto seems more intuitive to me.

@xenomachina
Copy link
Owner

This does seem to be a common source of confusion, so it's definitely something I want to improve.

To answer your question, though, here's what I posted in an almost identical issue yesterday:

the reason the "mainBody" is separate from "parseInto" is to make testing easier. mainBody calls exitProcess and also writes directly to System.out/System.err, and none of that is very easy to test. So the idea is that mainBody has factored out a bunch of difficult to test bits. The body you pass to mainBody can do nothing but call a "testableMain" method, and your tests can test that same method.

Given that, I am somewhat reluctant to have the default behavior be "make my code hard to test".

@xenomachina
Copy link
Owner

Duplicate of #64

@xenomachina xenomachina marked this as a duplicate of #64 Sep 7, 2018
@holgerbrandl
Copy link
Author

Thanks for detailing it out. Though, I personally would consider an easy and intuitive usage more important than testability.

Btw, what I did for https://github.com/holgerbrandl/kscript which suffers from a similar conceptual problem was to combine jvm-unit-testing with integration-level tests (error, exit codes) using assert.sh.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants