
Defensive programming framework for .NET Framework - aljazsim
https://github.com/aljazsim/defensive-programming-framework-for-net/
======
joshschreuder
I think PostSharp can do something similar to this also.

[http://www.postsharp.net/blog/post/Validating-parameters-
fie...](http://www.postsharp.net/blog/post/Validating-parameters-field-and-
properties-in-PostSharp-3)

------
rkagerer
Nice! Not sure I like littering so many methods onto extensions instead of
encapsulating in a Validate namespace, but I understand the convenience.

BTW small typo in the comments of your second set of example code: "thorws"

~~~
aljazsim
I will correct it, thank you. Good catch!

------
GiorgioG
Am I the only one that dislikes ArgumentExceptions - especially if I'm
consuming a library (without source.) IMO - exceptions should be for
exceptional situations, not invalid input handling.

~~~
nostalgeek
> Am I the only one that dislikes ArgumentExceptions - especially if I'm
> consuming a library (without source.) IMO - exceptions should be for
> exceptional situations, not invalid input handling.

Diving by 0 should yield exception for instance. Why not null? or odd when
even numbers are expected? ...

I think the problem with all this is that you really want a type system that
can do most of the validation job not at runtime, but at compile time.

Often OO languages force developers into some weird patterns (ex: value
object) in order to mimic functional or algebraic types, at run time.

Contract programming with static predicates can help as well, I don't know if
C# supports this.

~~~
usea
C# does have a feature called Code Contracts [0][1]. I haven't used them, and
in my experience they aren't super popular. They look like mostly convenience
for specifying when to throw, rather than as an alternative to throwing. There
is some static capability, but I'm not sure what the extent of it is.

[0]:
[https://github.com/Microsoft/CodeContracts](https://github.com/Microsoft/CodeContracts)

[1]: [https://docs.microsoft.com/en-us/dotnet/framework/debug-
trac...](https://docs.microsoft.com/en-us/dotnet/framework/debug-trace-
profile/code-contracts)

------
kyleperik
What makes this better than using regular asserts? Are asserts normally just
associated with automated testing in .NET?

~~~
keithnz
It essentially is asserts just more "fluent".

Not sure if I like it or not.

------
shapiro92
why framework? you limit the usage.

~~~
V-2
It's a nice bucket of handy utility methods, but that doesn't constitute a
framework as I understand the term

