[mrkeen]

Every C programmer is already doing it the 'good' way (validation), so this article doesn't really add anything.

The only fundamentalism involved in PdV is: if you have an email, it's actually an email. It's not arbitrary data that may or may not an email.

Maybe you want your emailing methods to accept both emails and not-emails in your code base. Then it's up to each method to validate it before working on it. That is precisely what PdV warns against.

[lmz]

You don't think there's a degree of difference between (valid email_t or null) and (valid char pointer or invalid char pointer)?

[mrkeen]

There's a huge difference. One is an email_t to validate and one is a char* to validate.

  As established, head is partial because there is no element to return if the list is empty: we’ve made a promise we cannot possibly fulfill. Fortunately, there’s an easy solution to that dilemma: we can weaken our promise. Since we cannot guarantee the caller an element of the list, we’ll have to practice a little expectation management: we’ll do our best return an element if we can, but we reserve the right to return nothing at all. In Haskell, we express this possibility using the Maybe type

^ Weaken the post-condition. In some contexts null might be close enough for Maybe. But is Maybe itself even good enough?

  Returning Maybe is undoubtably convenient when we’re implementing head. However, it becomes significantly less convenient when we want to actually use it! Since head always has the potential to return Nothing, the burden falls upon its callers to handle that possibility, and sometimes that passing of the buck can be incredibly frustrating.

This is where the article falls short. It might be good (the enemy of perfect), but it ain't PdV.