Devlog #10 - Don’t Hate The User

One of the most important unwritten (though I’m sure it is written somewhere) rules of writing good software is responsible error handling. I’m writing a desktop application, and personally, when I’m using a desktop application, I don’t like it when it suddenly crashes with no useful error message. This is especially possible in a desktop application written in C++, where irresponsible coding practices can lead to segfaults and other crashes without so much as a Java-style “NullPointerException”. It would be incredibly frustrating for the user to lose progress and not even know why.

Another potentially frustrutaing situation is when the program fails silently. It doesn’t quite crash, but when you ask a program to do something and it just doesn’t do it, that can be frustrating. When a program can’t satisfy an action the user wants it to make, it should make it as clear as possible that it’s aware of its failure, and attempt to clarify what went wrong.

What I’ve Been Doing Until Now

Up until now I have handled runtime errors by… well… not handling them. I wrote my application under the assumption that everything works smoothly, every module loaded by the user exports the correct signature, every file opened by the user is well-formed, and every file the user wants to write to has the necessary permissions. If any of this went wrong, the program entered undefined behavior. Most likely, it will crash.

My Solution

Whenever the user requests an action by the program, for example, trying to open a saved simulation state JSON, the program goes through the following steps:

1. Make sure the file is actually opened
2. Make sure the file is correctly-formed JSON syntax
3. Make sure the actual data in the file aligns with PSimUltimate’s requirements and constraints
4. Actually deserialize the file

If any of these goes wrong, the deserialization process immidiately ends and an error notification is pushed to the bottom-right corner of the screen. If multiple things are wrong about the data in the file, only the first thing in the deserialization order is written. There can be up to 3 error notifications displayed at once, with any more notifications being queued for when those are closed by the user.

This solves the issue of responsible, user-friendly error handling, and is an important piece of infrastructure for a usable desktop application.