Design for the error cases

I’ve spent a couple of months migrating some code from OAuth1 to OAuth2. I helped to shape the OAuth2 services, the first API calls in the new platform, set up all the new infrastructure in the client side.

Usually I like to have, as soon as possible, an end to end working case. It helps to validate the approach, helps to test changes on the server side; start writing unit tests, perhaps some hallway user testing, etc.

Then I add the error handling (what happens when there isn’t a network connection, or the server is not available, or returns invalid answers, etc.).

But after some time working on this project I think that I should have started the skeleton with the “usual” cases: what happens when it’s not working. And then at the end I should have handled the special case, the one that… it works.

So, consider the errors part of the usual code path and then, at the end, add “what happens when everything works well”. I’m exaggerating a bit but you probably know what I mean.

The code, in any of both approaches, is similar. But it avoids some back and forth to add error handling where I didn’t expect to have any.

Next time I’ll do this way. I’ll see what happens then!