I’ve been teaching myself C# for the last 2 years or so. I’ve got a reasonable handle on a lot of the language/ programming in general. However I feel like I’m massively missing the mark when it comes to debugging.

I deal with a lot of multithreaded and real-time applications that interact with physical hardware. I can set breakpoints and inspect variable values at the breakpoint, step into, step over, etc. But the “autos” and “locals” windows are something I don’t understand.

Are there any decent courses/resources that teach me some intermediate debugging skills. Particularly interested in resources that focus on Visual Studio tools (extra points for resources that include tips on VS Enterprises debugging tools, like step backwards, etc.).

Appreciate anyone pointing me in the right direction! I’ve learnt by feel up to this point, but I’ve hit a wall and could use some structured docs or courses.

    • Isaac95@lemmy.worldOPEnglish
      3·
      1 year ago

      Thanks for the link, and I agree with your sentiment. I don’t find myself debugging a lot. Perhaps why i neglected the skill. However just today I was getting a null reference exception on a particular line, yet I wasn’t able to clarify what object it was that was null. Seems pretty silly, but it prompted me to try and hone my debugging skills, as I felt the tools where there, I just don’t know how to use them.

      • CatPoop@lemmy.world
        2·
        1 year ago

        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.

        • Isaac95@lemmy.worldOP
          2·
          1 year ago

          Thanks for such a detailed reply, specific to my use case. Really helpful tips.

          and also a device simulator down to the byte/protocol level, then you can inject faults and ensure your app can handle them.

          I know I should do this, it’s just such a PIA for me since I hate reading/implenting standards so I’ve avoided it. Thanks for the push, I think I’ll make a start on one this weekend.

      • tbonebrad@lemmy.worldEnglish
        1·
        1 year ago

        If you are going to use Visual Studio I would highly recommend getting the resharper plug-in or start using Rider as you IDE. Having good tooling like this will help you see the possible null reference errors before you even finish writing your code.

      • canpolat@programming.devEnglish
        0·
        1 year ago

        Well… I didn’t say “you shouldn’t debug”, I said “[i]f you find yourself debugging a lot […]”. Debugging is a tool in our toolbox and we should use it whenever it’s necessary. But if it’s something we do too often, it may be an indication of a code quality problem (a bad smell, if you like).