Hacker News Reader

Comment by Aqueous | Hacker News Reader

Not sure what this author is saying here. Types have nothing to do with being able to trust other systems and everything to do with the internal formal consistency of the code that you write.

It's about being consistent with yourself.

If you find yourself writing defensive checks in fulfilled promise handlers because the data you get is sometimes invalid, stop. Get up from your keyboard, go to whoever owns the endpoint, and ask them why their endpoint is returning a 200 OK response with data that doesn't live up to its spec. This is a bug in their system, not yours.

View on HN

If your software crashes on bad user input, that's an error in your software.

By the way, there is distinction to make between library code that should exception/assert/abort on error and application code that should verify input and display an error to the user.

Correct - but in the case I described above, you (and your program) are the user.

You’ve clearly had a blessed and gentle career

I've worked for very large companies whose massive codebases are littered with defensive checks that have piled up over many years. Invariably, I find that this is because, when the initial wave of defensive checks inevitably broke down because they guard against something that itself changes behavior again, more defensive checks were added.

All of this could have been avoided if those companies had just created a culture, from the beginning, where you force the upstream data provider to fix its issues rather than coding around them by allowing code to fail-fast rather than gracefully.

Now companies are beginning to introduce integration and unit testing across the board and type systems (again, to ensure internal consistency for systems so that other systems can depend on them) and the cruft and defensiveness is slowly going away.

To repeat the old cliché, the best defense is a good offense :-)

>had just created a culture, from the beginning...

Were it such an easy thing...

Here's how I've experienced such things:

I write naive code. Application hard fails. Test environment down - everyone cross with me.

Me: Yo upstream - fix your data please.

...no response.

So I raise a ticket to get data source fixed - send it to the backlog.

Me: Yo delivery - can we get this ticket prioritised, assigned and put into a sprint?

Delivery: Yeah... nah - cause y'know... delivery.

Me: Yo leadership - can we get a decision taken on whether or not upstream should fix their data, or whether we should just program defensively? If the former - can someone tell delivery to tell upstream?

...no response.

At this point - I give up. Write my little defensive check and admonish myself to do so consistently from now on. Commit, push... go home - sleep like babe.

This is an unrealistic strategy.

Often the systems you're connecting to aren't maintained by people in the same office or company as you.

Every back end and front end system I've worked on as long as I can remember has had dependencies on third party API's. Getting bugs fixed in those APIs could sometimes take months ("change requests"), if at all.

Finding a good balance for how your system gracefully degrades is a bit of an art form.

Don't think it's unrealistic at all from within a single company.

The point about 3rd party libraries is taken but I also think if you are using a 3rd-party endpoint that publishes a specification that it then doesn't live up to (and takes months to fix) then it's not a reliable partner in whatever you're doing and is not living up to its own promises about the data its customers can expect. Like one of the other commenters here said, time to deprecate or write a wrapper around it that enforces the data contract.

I agree with this. I’m all for writing checks against values which may be optional, but I don’t litter my logic with checks against code that should provide the appropriate data.

If you’re getting bad data you need to address the issue higher up. Either through fixing your source or if you’re forced into some badly behaving library then you should at most write a wrapper around it and make that as isolated as possible. Then you should start making plans to deprecate that library.

The spec should be typed. Those other users should not just be giving you typed data, they should be giving you a type signature.

I'm referring to a general situation. You're referring to a specific situation of http apis sharing what I assume is untyped data and the typing is lost during transport. The solution is to develop protocols on top of http where the type signature isn't lost.

But the gRPC purist who wrote that endpoint while mandating that unit testing private methods is philosophically worse than genocide and using a slackbot to append “don’t write tests for the compiler” to every pull request got a huge payout to leave the company last year before sexual harassment complaints could move forward.

not sure why you're being modded down. i find this comment hilarious and it reminds me of individuals i've encountered.

I understand why it’s being downvoted, but I too find it very funny.

Reply on news.ycombinator.com