Added parse_and_check/2 function to verify all required options

[saleyn]

This patch adds a new function to verify that all required options have been given values.
It is a backward compatible change.

[jcomellas]

@saleyn Thanks for the patch. I had thought about adding checks for required arguments before, but I wasn't sure I could assume that arguments that don't have default values must always be present. That's why I left the task of checking the arguments to the user. The main issue I have with the patch is that when a required argument is missing, an exception is thrown instead of just returning an error. Also, I think we should return the atom with the name of the missing option instead of its command-line representation, as this error is going to be received by the application and not the end user.

If we were to include this functionality, I think it might be better to just add an additional function called check/2 that receives the list of parsed options returned by parse/2. What do you think?

[saleyn]

Can you think of a case when an argument is not given a default should be treated as non-required? It seems to me that it's always the case that you want to specify default behavior in one place as opposed to scattering it throughout the code, that's why I think it is a good assumption. I will rework the patch to split it in two functions check/2 and parse_and_check/2 that don't throw. This way it would give the user all control.

[jcomellas]

Normally, if it's an option, it should have a value, so in that sense I agree with you. It's just that the user might choose not to give it a default value in the getopt option specifications and set the value in some other way.

[saleyn]

Which is what we call the "default" behavior. ;-)
Perhaps in case when a type is specified, the default value could be a function, which would cover the case you mention that parse/2 would call that function to determine the value, so that it's not fixed, and not required?

[jcomellas]

Yes, it's a possible solution, but I think it's overkill for this particular case, as I'd prefer to keep the option specifications as "declarative" as possible. I also tried to add option validation a long time ago, but it becomes so complex so fast, that the only sane way to cover all the cases is to allow the user to provide a validation function for each option. I finally reached the conclusion that this problem was out of getopt's scope.

[saleyn]

Ok, I pushed the changes we discussed. This version gives the developer control over required and optional argument checking and also adds the error formatting function for reporting.

[jcomellas]

OK, I'll merge the patch, but for consistency I will change getopt:check/2 to receive the list of option specifications as the first argument. Thanks!

[saleyn]

Thanks! I also just checked in the test cases for new functions.