CatPoop

System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection.

If you haven’t already done so i’d recommend enabling nullable types, at the very least it should make your code more robust against this particular error, and may help narrow down where exactly the null is set. I’ve only seen one null reference exception since I turned this feature on, and it was because I mis-used the null-forgiving operator..

The debugger is important in the immediate stage of coding, but high quality logs will make your life much easier through all stages of the software development lifecycle.

Regarding real-time / system software, all IO and new threads must always be wrapped in exception handlers, and every handler must do something in the catch block, if nothing else log the exception, I usually dump the stack trace as well if I’m not really expecting it to reach a particular block, most of the time the stack trace makes the debugging trivial.

If you are working with sensors/devices, it’s good practice to write a driver, and also a device simulator down to the byte/protocol level, then you can inject faults and ensure your app can handle them. Don’t be afraid to throw exceptions, e.g. if your sensor message parser doesn’t understand the format, throw a FormatException; then you’ll safely walk back up the stack and combined with good logs the issue should be straightforward to diagnose.

Multithreading is a minefield, but you can eliminate a whole class of errors (race conditions) by embracing async/await. Avoid side effects at all costs and try to write pure functions only; never use ‘flags’. Use the concurrent collections, and try to avoid locks where you can; if you must, get in and out of the critical section as fast as you can, or you will degrade performance and increase the possibility of deadlocks.

Might have better luck getting meat from a local butcher, the supermarkets are notorious for pumping up the weight with water.

I was walking down one of the isles today and shocked how small the condiment jars have become. (What is this? mint sauce for ants?)

Also recommend OneDrive, iOS app works great for automatically syncing photos, and has a decent document scanning/pdf feature I use a lot.

I’m on 175mg/day and get ‘earworm’ at least a few times a week, it’s interesting to find out it might be related!

An exception will bubble up the stack until it enters a catch block that can handle it, and you may need additional logic to decide if you are finished, or it needs to go further up. (you may also intercept it just to add more data, or log it)

throw; allows you send the original exception further up, but throw ex; behaves the same as throwing a new Exception object, and therefore has a new trace. The throw statement doesn’t query any properties on the exception argument AFAIK, so it has no idea this exception has been previously thrown, but the IDE is smart enough to know you almost certainly don’t want to do this.

I really like nullable types, they can be very effective for writing safer code.

Sometimes there are good reasons to separate object construction and initialization (e.g. composite / loosely coupled objects, or encapsulation of 3rd party libraries) so there can be properties/fields that do not yet have valid values, and using separate queries for this is error prone.

I write a lot of communication interfaces for sensors/actuators and if the communication drops, nullables are a good way to represent invalid readings.

Being able to convey the value and validity in one variable can be more thread-safe and easier to write pure-functions, and show intent.

I occasionally use a nullable for singleton patterns if I’m not 100% convinced there can never be multiple instances, rather than painting myself into a corner with a static class. e.g.

public static MyClass Instance => _instance ??= new();
private static MyClass? _instance; 

I develop .NET and python on windows in Visual Studio and do the debugging there, then when it all looks stable I’ll commit to git. Then on an arm system, the docker files will pull from git to build the containers, and I’ll do the end-to-end testing there, and rely on the debug logs rather than bothering attaching a debugger.