CollectionArg methods disregard optsFn for null checks

[DennisInSky]

CollectionArg methods disregard optsFn for null checks
https://github.com/danielwertheim/Ensure.That/blob/master/src/projects/EnsureThat/Enforcers/CollectionArg.cs#L19
unlike it is done for StringArg
https://github.com/danielwertheim/Ensure.That/blob/master/src/projects/EnsureThat/Enforcers/StringArg.cs#L17

[danielwertheim]

@DennisInSky what use case do you use the options for? The reason for me asking is that I’m leaning against removing it. Why? Because the lib should only be for argument validation (guard clause) and not for generating custom business exceptions etc. And if so, what in options is needed?

[DennisInSky]

@danielwertheim I am using it for for guard clauses, but in some cases I want them to throw custom exceptions which I can handle and return error messages in a more user friendly way.

[danielwertheim]

@DennisInSky how would you feel about a "Scope" construct instead? See #165 for a sample.

[DennisInSky]

Well, I haven't dived deeply into the code, but will the scope affect all the clauses in the nested calls? I would definitely not want it. Your intent is to avoid using this library for throwing custom exceptions, but what is the reason of using it at all if I have already verified conditions using some other means which allow me throwing custom exceptions? I do not think one would like to write double checks.

[danielwertheim]

but what is the reason of using it at all if I have already verified conditions using some other means which allow me throwing custom exceptions?

What do you mean by "if I have already verified conditions"?

As long as you are in the scope that would provide scoped data for the exception factory. Which, yes would make life more cumbersome, as you probably would encapsulate your custom "rules" in a method e.g. EnsureFooIsValid(foo).

[ndrwrbgs]

link to #165