How to handle errors like a champ

This work is licensed under CC BY-NC-SA 4.0. To view a copy of this license, visit https://creativecommons.org/licenses/by-nc-sa/4.0

This is a good representation of a error:

https://dlang.org/images/dman-error.jpg

Think of all the D's out there suffering! Donate now!

Errors are a normal thing for a program to have, but some programs handle them better than others.
This is my personal opinion on how to handle them.
Let's make a couple of assumptions:

• Errors are not normal
• Errors indicate a problem (except info)
• Errors can cause a program to malfunction

And here's my non-definitive list of errors:

• Info
• Warning
• Non-Fatal error
• Fatal error
• Termination
• Core dump/segfault

Info

This is a non-error.

You're walking down the street and you text your mom where you are.

You'll get these messages when you use a -v or --verbose option.
For example:

starting to foo the bar
Fooing bar: OK

Or, from FFMPEG:

  configuration: --prefix=/usr --disable-debug --disable-static --disable-stripping --enable-avisynth --enable-fontconfig --enable-gmp --enable-gnutls --enable-gpl --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libdav1d --enable-libdrm --enable-libfreetype --enable-libfribidi --enable-libgsm --enable-libiec61883 --enable-libjack --enable-libmfx --enable-libmodplug --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-librav1e --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libssh --enable-libtheora --enable-libv4l2 --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxcb --enable-libxml2 --enable-libxvid --enable-nvdec --enable-nvenc --enable-omx --enable-shared --enable-version3

These are useful, but should normally be hidden behing a -v or --verbose option.

Warnings

This is a kinda-error.

You're walking and you stub your toe

It hurts, but you can recover quickly.
For example:

Trying to foo the bar
!! Cannot foo a float, converting to int

Or from the GCC:

warning: left shift count >= width of type [-Wshift-count-overflow]
4 | x <<= 63;

These should be visible, but should never stop or interfere with program operation.
Hide them behind --no-warn or --quiet

Non-fatal error

This is an error that can cause the software to drop into a reduced mode, disabling function.

You walk and someone stabs you in the leg

You can keep limping along, but it hurts and you should get help fast.
For example:

cannot foo the bar: bar is a string
Skipping.

From systemd:

Failed to start mine.service.Unit mine.service not found

It can't fin the service, but it keeps on chugging on.

These should be raised, but not stop.
Make them loud.

Fatal error.

This is when you can't keep going but you can at least tell why:

You are walking and get stabbed in the chest. You croak out your last words: "btw I use arch"

(I do not support this)
This hurts, you can't keep going but you can at least say something.
For example:

fooing bar
ERROR: bar: no such file or directory

You're trying to foo the bar but there is no bar.
What do you do!
You will loudly complain, let the user know why
Then, give some help, if any, and exit.
From cat:

cat: lolcode: No such file or directory

Termination

This is when you can't even tell why, but you exit cleanly

You are walking and you fall down a ravine

You can't save yourself and you can't tell why
There's no way to tell why.
For example:

[1]  + 12164 terminated foo bar

Core dump/segfault/panic

This is where you can't tell why, and you make a mess:

You swallow a grenade ...

For example, a segfault, or a kernel panic:

Kernel panic - not syncing: Attempted to kill init!

(though it can print a message it's not a very good one)

After reading this, please, consider how your program handles errors and how you let the user deal with them.
Thanks for reading!