Expecting the Unexpected
Murphy’s Law states: “Anything that can go wrong will go wrong”. Ordering a coffee and getting the wrong drink? Murphy’s Law. Dog ate your homework? He probably didn’t, but Murphy’s Law. The app you are using unexpectedly crashes? Yet again, Murphy’s Law.
One of the greatest things about designing and developing software is the unexpectedness of scenarios you would have never considered. 1 out of 10 times, the unexpected is welcome, but the other 9 times out of 10, the unexpected just causes major headaches. Applications should work 100% of the time ideally, but we’ve all experienced the occasional “bug” or crashing of our apps due to errors. There are many reasons why an app can fail, but for this post, I will be focusing on missing data and how this affected my development of Spotify Voice.
But first, let’s see how pets can give a good picture of error handling.
The Unexpected Behavior of Dogs and Cats
If you have ever had a dog or cat, you will notice they tend to misbehave from time to time. Sometimes, their misbehavior is just a minor annoyance that doesn’t affect you drastically such as when your dog barks at the neighbors or when your cat invades your personal space.
Other times, their misbehavior will cause you a lot of trouble such as when your dog is not potty-trained yet or when your cat scratches up your furniture. In any case, minor misbehavior usually does not require any action from you, whereas major misbehaviors do.
Error handling is very similar to this idea of minor and major misbehaviors of dogs and cats. Sometimes, an error will happen, but it won’t affect the usability of the app, and so, the error doesn’t need to be handled. For example, Spotify Voice tries to remove the currently playing song from the spotify_voice playlist on a like. What happens if you like the song again? An error occurs because the song is no longer in the spotify_voice playlist, but it doesn’t stop the app from working, so just let the error happen. Other times, an error would happen and the app would crash and be completely unusable, so the error must be handled. For example, when Spotify Voice tried to get data that didn’t exist, it would crash. The severity of these errors differed due to the way I designed my app.
Let’s now examine some of these major, app-crashing errors.
The Ghost Track
A few weeks ago, I was using Spotify Voice, and it stopped working all of a sudden after I skipped a song. I was a little annoyed at this, but thought that it was just the authorization token expiring.
Minor digression. Basically, when the app is first loaded, there is a token that the app uses to send and receive data from Spotify. This token is only valid for an hour (for security reasons I won’t get into), after which, the app has to ask for another one. I have not implemented the asking for another token, so whenever I use Spotify Voice for more than an hour, I just go back to the previous page that asked for me to login to Spotify. This is unintuitive and inefficient, I know, but until I implement that feature, this is my work around.
Back to the problem at hand: I figured out the problem was not the token expiring because it had only been 20 minutes since I opened Spotify Voice! After an hour of digging around, I finally discovered a “ghost” track in the New Music Friday playlist for that week.
If you look at the “track” label for items 52, 53, and 54 above, you will notice that item 52 and 54 seem to have data regarding a track. For some reason, item 53 has no data which can be seen by the “null” value. Since this data should be a representation of what is shown in the actual Spotify application, I went and looked at the New Music Friday tracks to see if the ghost track was there.
Track 52 was All Over You by Majid Jordan and track 54 was Summer by Chloe Lilac. As you can see, track 53 is not here! When I got to All Over You and skipped the song, my app tried to play the “next song”, which was the ghost track, and crashed because the ghost track didn’t exist. This was a hard problem to investigate because visually, there seems to be nothing wrong with the playlist. Behind the scenes, however, the app was working with the playlist data, which included the ghost track.
To solve this problem, I added a check when constructing the spotify_voice playlist to only add a track if it existed (i.e. the value in the “track” label is not null). In the end, it took a couple hours to figure out the problem and only one line of code to fix it; now that’s what I call efficiency…
Missing Art
Another instance where I encountered missing data was the retrieval of the album cover when a song is skipped. A couple of weeks ago, Without You by leftprojects did not have an album cover. So, with the way my app was programmed, it would try to pull down a picture that didn’t exist, thus resulting in the app crashing. The fix here was also a simple one-liner that checked for the existence of an album cover before trying to retrieve it. In hindsight, I probably should have read the Spotify API documentation about how data is not guaranteed to be present sometimes.
Lessons Learned
Error handling is difficult because it requires one to think about all the possibilities of things that can go wrong. Sometimes the errors don’t require you to take any action since the app still works completely fine. Though, there are bound to be errors that will require some action because the app will totally malfunction otherwise. This is part of the reason why apps update frequently: patches are being applied to resolve some of the errors.
Murphy’s Law seems to accurately describe the relationship between errors and software, but that’s not a bad thing. As long as the errors get fixed, the application’s usability will improve as a result. As for error handling dogs and cats, good luck!
Song of the Week
Take a Walk by Passion Pit [Spotify][YouTube]
The violin cover, by Vitamin String Quartet, of this song is also awesome!
