A Tale of Poor Exception Handling

Today we have a tale of good intentions and failed implementation. A tale of misleading results and frustrating debugging. A tale that has happened countless times in software systems around the world and will continue to happen countless more times in the years to come.

Our tale begins as our hero starts a new week. The previous week was a big one for our hero, who finished the week with the merge of a major update our hero’s team had been working very hard on. This merge was rather large, so our hero was paying very close attention for strange application behavior that could be attributed to the merge.

During the morning status meeting, the team begins discussing the fact that a team member has not been able to log into the app since they arrived earlier that morning. Our hero becomes concerned, pulls down the latest code, and runs the app. Sure enough, the app is preventing users from logging in.

Our hero’s quest has begun.

The application in question is a mobile application which connects to a back-end API. The code has been developed by a third party, which is no longer involved. The application was originally developed as a proof-of-concept. Alas, the proof-of-concept code became production code, bringing with it all the proof-of-concept “get it done quickly” decisions and technical debt. It is at this point that our hero’s team becomes involved.

There are many points at which a failure could be happening to prevent a user from logging in to the application. Our hero begins by adding breakpoints to the mobile application code in the hopes of finding an obvious cause of the problem.

The first pass through hit one of the expected breakpoints, then skipped the rest and instead hit the breakpoint in the exception handler block. The “exception handler” block does nothing more than log the exception and move on. In other words, it swallows the exception. Since our hero’s team is not responsible for this code, it is not their responsibility to fix it at this time. Our hero notes that the exception being caught is a NullReferenceException. Our hero finds this highly unhelpful and is forced to run the code a second time, this time stepping through each line of code after the first breakpoint. Lo and behold, our hero finds the offending null reference. It is a variable that was returned from a method as null and was subsequently used by the remaining code without a proper null check. Thus, the NullReferenceException.

To learn the true cause of the null reference, our hero must dig deeper.

Our hero runs the app a third time, eventually stepping into the null returning method to find yet another exception swallowing block catching yet another NullReferenceException. This exception swallowing block was slightly different, though: it returns null in the case of an exception. Our hero is looking at a method which catches a NullReferenceException and handles it by itself returning a null reference.

Our hero comes to the cold realization that this is going to be a very long quest.

Undaunted, our hero forges on. Method after method, our hero descends the call stack. Battling missing null checks and swallowed NullReferenceExceptions at every level, our hero is determined to find the source of the problem. Deep down, in the bowels of the application code, our hero scrolls and steps and scrolls and steps until… Finally, our hero sees something different! Through blurry eyes, our hero squints at the code on the screen.

What is this? our hero thinks. It looks like an HttpClient…

It is!

Wait… It’s receiving a 500 error from the server.

At that moment, after tracing the nulls through a labyrinth of unnecessarily complex code with extremely poor exception handling, our hero is staring at the abyss as the sad understanding washes over.

The original error isn’t coming from the mobile code at all. It’s coming from the API code on the server.

Our hero stares incredulously at the code for a moment longer. Then, unwilling to be bested by poorly written code, our hero takes a deep breath and leaps into the abyss.

It’s dark here. And cold. So cold.

Our hero takes a moment to survey the surroundings. This is the server, all right.

Our hero gets right to work looking for the logs. A few clicks later, the logs are on the screen and our hero begins inspecting them.

There’s the authentication request! And there’s the error! Hooray! The API issue is going to be easy to diagnose!

StringFormatException, our hero thinks. I can look at the API endpoint code to find where a string is being formatted incorrectly and claim victory!

Our hero does just that. There’s the API endpoint code. A quick scan of the method and… There! That’s where the code is incorrectly formatting the string! The IDE has even helpfully underlined the offending code with a green squiggly. Problem solved!

Wait a minute…

What is that code trying to format?

It looks like it’s trying to format an exception message…

Our hero quickly looks the code over. Sure enough, the code in question is the exception handling block. The exception handling block is catching an exception, then failing to format a message with it for the logs, and, therefore, causing the API to return a 500 error.

Our hero’s heart sinks.

More poorly written exception handling code. More line by line debugging and traversing the call stack.

Our hero rallies.

It can’t end like this. I must find the source of this exception!

Our hero sets up the server code for local debugging, sets some breakpoints, takes a deep breath, and sends a request.

Line by line, method by method, our hero continues the quest. This time, battling StringFormatExceptions.


There it is. The cause of all of this. After seeing several exception handlers catch exceptions and then throw their own due to poorly written string formatting code, our hero is staring at the real root cause. A null reference that is a true null reference. Not one caused by poorly written exception code. But an actual null reference caused by a member being used without being properly initialized.

Our hero looks at the commit history. Sure enough, there is code that was inadvertently removed by a team member.

Our hero re-implements the code and runs the server code locally again. This time the server code handles the request flawlessly. Our hero gets excited. The mobile application moves past the login screen.

This is real progress!

The mobile application continues to show the loading spinner. Our hero waits patiently. Seconds tick by. Our hero gets anxious.

Then, a flash. The mobile application changes screens. Success! The user can log into the app now!

Our hero sits back, exhausted, and looks at the page displayed by the mobile app.

Wait. Something is wrong. That’s not the correct page.

Our hero quickly brings up the code that navigates the user after logging in, sets some breakpoints, and runs the application again.

First breakpoint hits. Excellent. Next breakpoint… Wait. Exception handler breakpoint?

Our hero stares at the screen in complete disbelief.

A NullReferenceException.


Coding with Kids

As a professional software developer with four kids of my own, I’ve played around with different ways to introduce my kids to some of the basics of coding. We’ve tried a few different tools and exercises and my kids always seemed to enjoy it.

However, I never took it beyond just some fun with my own kids. That is, until my oldest daughter suggested I try sharing some of it with her class. That suggestion got the ball rolling and, before I knew it, I had a date lined up with four different classes comprised of over 100 kids at their Montessori school.

The experience was awesome.

We broke it up into three sessions, with the first session being older kids (grades 4-6) and the other two being younger kids (grades 1-3). In the process, I learned a few things about what worked well and what didn’t work as well.

In this post, I’d like to talk about what tools I used, the plan I came up with, the actual execution, and what I learned from it all. It was a lot of fun and I saw that the kids were really interested in learning more about working with computers. Hopefully my experience will inspire other software developer parents to at least sit down with their kids and explore the world of coding. Who knows, maybe that will lead to a day of coding at their school too.

The Tools

Right now is an excellent time to teach kids how to code. There are a lot of great tools out there that take different approaches to learning. And it’s becoming “cool” to learn how to code. That combination opens up the door to a much more broad audience than ever before. Below is a list of technologies my kids and I have played with:

  • code.org – This might be the best place to start (and it’s what I used with the school kids). There are Hour of Code activities, teaching materials and plans, and they now even have a very nice and simplified visual coding environment.
  • Scratch – Developed by MIT, Scratch is a very popular visual coding environment. It was developed long before the code.org environment and it’s a little more advanced. This is the logical next step for kids after they feel comfortable with code.org. My 6 year old even enjoys just playing other kids’ games (you can create a free account and share your games with others). Here’s a good place to start, if they haven’t already tried Scratch: https://scratch.mit.edu/projects/31407152/
  • Scratch Jr – It’s Scratch, but aimed at younger kids. This is another good first step because it is another very simplified visual coding environment. It’s a mobile app that works best on a tablet.
  • Swift Playgrounds – This is an iPad app that teaches kids how to code using Apple’s Swift programming language. Swift is used to write apps for iPhones and iPads. The app has a similar sort of feel as some of the Hour of Code exercises from code.org, but it’s real Swift code that the kids see and work with. My 9 and 12 year olds really enjoy this one.
  • Beginning Game Programming for Teens – This is an article about game programming with Python written by a teen for teens. It’s definitely more advanced than the other options so far. However, it introduces kids to writing actual code, not just a fun and colorful abstraction layer. I followed along with it a while back to see if my kids would like it and was able to make his examples work, with some minor tweaks. Hopefully that was only necessary due to my setup, though. My kids weren’t quite ready for this one yet when they tried it, so it kind of faded away.

Other than the Game Programming article, these tools are aimed at absolute beginners. They abstract core programming concepts such as commands, variables, logic flows, and looping with an easy to understand visual approach to coding. They are very approachable, even for non-technical people, to help kids begin to learn what it means to create a program, see the results, and debug it when something doesn’t work as they expect.

The Plan

For my day of coding with the kids at school, I chose to use materials and the development environment from code.org. I worked out a plan that kept things simple, yet fun. It was comprised of three parts:

  1. Overall introduction to computers and coding. Talk about how important computers are in today’s world. Yes, smart phones and tablets are computers.
  2. Introduce the concept of commands using Graph Paper Programming. This is a physical exercise in which kids write “programs” that their partners will “execute” to fill in cells of a grid to make pixel art.
  3. Make a game from scratch using the Play Lab. The game I chose to do was called “Chase the Zombie”. Add two “actors” to the game, one to control and the other to catch. Simple enough to program in 45-60 mins, yet still fun enough to keep the kids engaged.

For the older kids, we planned to let them use Chromebooks provided by the school. We scheduled 2 hours, with the intention that the kids would have the last 30 mins to start to explore and roam, while I help out when they get stuck or have questions. The group was going to be fairly large (~60 kids) and the school doesn’t have enough Chromebooks for each student to get one. However, I actually saw benefit in having them pair up. After all, Pair Programming is a thing for a reason. I was hoping pairing the kids up would cut down on the number of questions I would have to answer overall.

For the younger kids, I thought it best to project my screen and do more of a guided session. I was hoping that would give the kids the opportunity to see it happen and play around as I keep it interactive and ask for help throughout, but not put the responsibility on them to completely drive the process. We planned for 1.5 hours for the younger kids.

The Execution

On the day of, the older kids were up first. Again, we had them organize into groups of 2 or 3. That really did help cut down on the number of questions because they didn’t need to get me involved until all the kids in the group were stumped. With that many kids, it was still pretty loud and chaotic. However, it seemed as though the kids were excited about the experience and I got a positive vibe overall from the room.

We started out with a brief intro, then started getting into the Graph Paper Programming exercise. I think the best thing to do for this would be to work through one example as a group, before turning them loose. That was my first lesson learned. In the interest of time, I described what needed to happen, then set them loose. Some kids understood how it worked right away and others needed to be walked through it more. Overall, this ended up going fairly well, once everyone understood what they were doing.

Next up, we switched gears to the code.org development environment with the promise that the kids would be making a game from scratch. That got them pretty excited. I projected my screen and walked the kids through the environment, then got to business. I had planned out how to layer the pieces in with a sequential story of sorts. For example, “Add an actor to your game. Now run it. Ok, now should we make your actor move down? Good, now let’s make the actor move all the other directions.” And so on.

Early on, I could tell that some kids already had some experience with coding and it became obvious that making them stick to my plan would hold them back. So I let those kids roam free for the majority of the hands-on computer time and focused on the kids with little to no experience. It was neat to see what the experienced kids came up with along the way. However, that did cause some distraction to the lesser experienced kids because they sometimes saw something different than we were doing and wanted to try it, then get stuck. Overall, it was just short of chaos, but the process still went surprisingly well. 2 hours ended up being the right amount of time for that group.

After wrapping up with the older kids, it was time to move on to the first group of younger kids. Unfortunately, we got started a little late, due to a miscommunication. However, the time we had ended up being just about perfect. The Graph Paper Programming went about as well for them as it did for the older kids, which is to say it went well with some room for improvement. The decision to make the code.org portion a guided exercise proved to be a good one. The kids loved to be able to see the game take form, especially being chosen to test it out at every step. Overall, really good engagement from them. My 12 year old, Grace, was also able to tag along and help answer questions too, which was fun.

Moving on to the final group of the day, the second group of younger kids, everything seemed to go by much more quickly. Probably due to a combination of starting on time and myself having had some more practice leading the experience by that point. This group was also very engaged. They had great questions, threw out some great ideas to try, and were just about jumping out of their seats to be chosen for each of the test runs. It went by so quickly and smoothly that we found ourselves finishing up with my prepared plan about 30 mins early. We used the opportunity to cover some additional topics and even make another game from scratch.

What I Learned

First off, I had a great time doing this. I had done a practice run with my kids and some neighborhood kids in the weeks leading up and was able to make some tweaks to my approach. I think it went very well overall and it sounds like the kids agreed. My kids told me after school the next day that lots of their classmates were working on coding throughout the day, which I was happy to hear.

Here’s the lessons I learned:

  1. The first lesson I learned is actually something I already knew to do from presenting at conferences: practice. Doing a test run with my kids and some neighborhood kids validated that I could do what I needed to do in the time planned. It also showed me some things that could be improved in how I framed the conversation.
  2. The next lesson I learned is in regards to the Graph Paper Programming, as mentioned above. Take the extra time to walk through an example prior to setting the kids loose. We also only spent around 20 mins on this exercise. I don’t feel like it was too rushed, other than some kids needing further explanation. But I do feel like that exercise alone is interesting enough to make stand alone session. That’s how they planned it with the code.org materials as well. However, I wanted to use it to kick things off, then move on to making a real game.
  3. With a younger kids, particularly 1-2 graders, it really helped to keep the coding portion more of a guided group exercise, rather than an individual hands-on exercise. The kids seemed to still really enjoy it without dealing with the confusion of not understanding what to do next.
  4. With the older kids, I learned that there are kids out there doing this stuff already and they can do some neat things with someone there to answer questions along the way.


The biggest take away I had from this experience is that there is a lot of curiosity around coding out there. Not all of these kids are going to grow up to be software developers. However, that didn’t stop them from having fun learning about how computers work and how to program them. I really enjoyed having the opportunity to introduce them to it and being there to experience their excitement as they were able to make a game of their own come to life.

Hopefully this is only the first of many such opportunities!


I’m speaking at NDC MN 2018!

Norwegian Developer’s Conference (NDC) is one of those conferences I’ve heard about for years and always wanted to check out someday. Since it was located in Norway, I didn’t think I’d ever get the chance. However, it’s coming to St. Paul Minnesota May 7-10 2018, and I’ve been selected as a presenter! It really is an honor to be selected for a conference with as much global reach as this one and I’ve very excited for the opportunity to present at it.

My session is Go Mobile with Xamarin, which will be an introductory discussion about mobile development with Xamarin for Android and iOS. I’ve been working with Xamarin for several years now and am looking forward to sharing some of my knowledge with NDC MN.

If you’re in the area, come check it out. There’s a lot of great speakers lined up and it will be a great opportunity to learn a ton.

See you there!

Mirror Maze 2.0 Has Been Released!

I’ve been hard at work these last few months on the new version of Mirror Maze. After initially releasing Mirror Maze, I had a number of ideas that I wanted to implement. Today, I’m excited to announce that Mirror Maze 2.0 is live! I’m really happy with how the new ideas turned out!

I completely re-envisioned the game types (with the help of my kids), bringing 7 new game types and 250+ new mazes to 2.0! It was a lot of fun bringing these ideas to life and I hope you enjoy the updates.

You can learn more about Mirror Maze 2.0 over at the marketing site.

Mirror Maze 2.0 is live in the App Store and Google Play. Go check it out!