examples/macros.rs failed when running without arguments

[Daimonion1980]

I have another behavior that possibly could be fixed.

When running the example examples/macros.rs and not providing any arguments (i.e. not providing the -n argument) the application panicks instead of printing the help message.

I think the application crashes when try to execute the macro in line 426
The get function which is called by this macro works, but after that something weired is going on I do not understand. ;)
The first argument -h is processed correctly from __parse_arg and the .get function. This returns ArgumentRef.default_value as ok. After this the next call from __pars_arg crashes.

Failure message at this line is: "Tried to unwrap argument that wasn't passed"

[Kyllingene]

This is the intended behavior of sarge: notice how there's no #ok/#err before the argument, which indicates that if you don't pass it, it'll panic.

Perhaps I could change the panic message, or change the example to put print a message rather than panicking?

[Kyllingene]

Hmm, when cleaning up the macros example, I noticed its help generation is also not right. I'm investigating now, but I don't know what could be causing it.

[Daimonion1980]

notice how there's no #ok/#err before the argument, which indicates that if you don't pass it, it'll panic.

Actually I use #ok, but maybe #err is what I need. I will look into this.

Perhaps I could change the panic message, or change the example to put print a message rather than panicking?

I am writing a CLI Application where 3 string option arguments are mandatory and when they are not given the application shall print a failure message together with the help output.
The example/macros.rs code fit this needs, because when parsing fails an error message and the help is printed.
But when I try to use this example the only way I can handle the 3 mandatory args is when using it with #ok/#err and check if the parsed option/option<Result<T,_>> are provided with values != default(T)

Furthermore I am not a fan of code which panics. ;)

Hmm, when cleaning up the macros example, I noticed its help generation is also not right. I'm investigating now, but I don't know what could be causing it.

Maybe there is a failure which led to this panic.
At the moment I don't understand this line

Thank you for your investigation!

[Kyllingene]

But when I try to use this example the only way I can handle the 3 mandatory args is when using it with #ok/#err and check if the parsed option/option<Result<T,_>> are provided with values != default(T)

Unfortunately, there's not much I can do about error messages: besides some panics, error handling is outside the purview of sarge, so #ok is what you need for ensuring strings are passed. There's not much I can do about that, since everyone handles errors differently. Therefore, the current panicking behavior is intended, though I've updated the example to instead handle the error.

Maybe there is a failure which led to this panic.

The issue isn't a panic; it's that subsequent lines of documentation don't get printed with indentation. I really can't figure out why, the expanded code seems like it ought to work just fine.

At the moment I don't understand this line

__parse_arg is what's responsible for handling how each argument gets handled. Depending on which tag (#ok/#err/none) gets passed, and whether or not there's a default given, the macro will handle missing arguments and parsing errors differently.

Notably, if you give an argument that has no default value (for example, bools always default to false if not passed, while strings have no default) no tag, and it doesn't get passed, sarge has no option but to panic. What else could it do? You told it not you give you an error, so the only thing it can do is panic on the spot.

[Daimonion1980]

Hmm, I understand.

Think that my not understanding is because I'm pretty new to rust and don't know how the code and macros works.
Until I understand the code I am fine with #err and default values on my string arguments.

Thank you!

[Kyllingene]

Happy to help! Note that for string arguments, you probably want #ok: all err gets you is letting you know if the argument fails to parse, but strings can't fail to parse.