Exception handling in coding and life

Part 1/2: the »technical« perspective.

Part 2/2 will be looking at it from a different point of view. Stay tuned!

---

The opposite of exceptional is ordinary.

Today was – almost ordinary.

Just another ordinary day at my laptop.

💻☔️🌧️🌦️🌈💻

It was a rainy weekend, so I sat down over some bureaucratic stuff first, to then get back to my code.

While I am looking for a job, my favourite waste of time besides discussing things way beyond smalltalk with a friend, fixing issues way beyond coding, swimming, reading, painting – and writing here – is that I like to make headway on one of my pet projects on GitHub.

Pling, new message. Someone commented on something I wrote. Let’s stay focused. Going to read that later in the soccer pause.

Today, it was about calculating an average of some list of integers.

No worries, I won’t bother you with code here. It’s just a fancy little mobile app I wrote to sum up points we do in card games.

If you already follow me on LinkedIn, you’ve probably read about it. 🔔

So today, I’d like to know the average of the points.

That’s pretty much all of it.

Wait. I hear a mosquito 🦟 coming along into my place, right next to my ears. Bsssssssss…………. Argh. Let’s handle this exception first… done. Back to the code now!

So okay, refocus. After I’ve written some code, I always test it. This time, I found that the code would raise an exception if the list was empty. 🙄

Let’s look at this a bit closer:

An exception in coding –visualized

An exception can be imagined like a stop mark on the code at runtime. I often visualize an exception without catching it as jumping out of a bus on a busy road.

🛴🛵🚦

Catching an exception within an app is like arguing with a passenger in a bus who can stay in but has to pay an extra price for ticket. If the passenger is nasty enough, however, the bus stops and they get him out.

Technical exceptions

My dishwasher if it doesn’t find water: resumes it’s task as soon as the water is fine again. No pressing a button, no beep. Only the (also for the blind ones) different noise it makes and an LED sign on it.

If a car raises an exception, it’s mostly that someone in the back row had unfastened their seat belt, the gas tank is almost empty, or something like that. Still driving.

Thankfully, no car of today would return a BSOD and refuse to fuel the engine on a highway for a little sort of nothing.

Lucky you are.

Arriving on time you can.

(I am thinking about sharing a story of a weird car my father bought in the early 90s that almost did even that, though…)

In fact, even Windows 98 didn’t do that – after the blue screen, the office file was still open but reset to some recently saved state. Phew…

Looking closer

In coding, different steps can follow, from light to heavy, such as:

• Resuming the last task, e.g. on bad internet connection

• Invoking some fallback routine without letting you know

• Letting you know that something is wrong so you can fix it

• …

• Messaging you that the app has stopped.

Most of exceptions are handled rightaway by letting you know:

• Displaying a message to the user

• Some alarm signal

• Some (usually only halfly helpful) advice on deleting your cookies, checking your internet connection or something like that.

Regarding the user messages:

I have seen all the way in history from frozen screen with busy humming CPU saying nothing until you push the on/off button, over to BSOD on to a half-postcard-sized message box apparently addressed to a CS student 🙈like some »memory 0x… was failing« to a polite, but sometimes inaccurate message in a »snack bar« at the bottom of your mobile app! 📱

---

Next: Just another ordinary day at university. Until it was not …