Forgot to actually answer :)
On Sun, 28 Jul 2013 11:35:21 GMT, Manu Evans wrote:
1) An outer block to catch validation exceptions doesn't customise the error for whatever particular thing is missing.
It can assuming you store that information in the exception.
2) Once past the validation process, an unexpected exception will still be caught by the same outer catch that caught the missing args, unless you start messing with specific exception types, which in turn precludes generic handling of argument exceptions.
"outer" was meant to be "outer for validation code scope"
3) If you go to the effort of defining and throwing specific exceptions for various cases, and/or catching a general exception and performing a bunch of logic to decide what the error case that threw actually was, either way, that's a lot of logic. I don't imagine that's less lines, or more readable than just handling the missing argument with an 'if' at the point I first grab it...
It is not. I don't care how many lines is trivial app long - it is much more important that those lines won't get copy-pasted once application grows. Sanitizing user input can't be short, it is plain impossible. If it is short, it is most likely to not handle validation properly. However, you can move all that clumsy logic into generic helpers and forget about it, focusing on "business logic" (hate this term).
Can you demonstrate what code would look like that:
- Validates some args, accepting that some args are optional.
- May receive the args from either post, query, or path args.
- Gives the opportunity for customised error output for the particular thing that was missing.
- Doesn't require additional logic to perform those tasks; should be less code/simpler than an if.
Hope snippet above somewhat answers that. Other than last point but as I have already said, I dismiss it as an improper desire :)