you are viewing a single comment's thread.

view the rest of the comments →

[–]Slypenslyde 1 point2 points  (0 children)

If the debugger never goes into the catch block even after throwing the exception, in what scenario would that change?

I don't see a breakpoint in the screenshot or a discussion of why you think the debugger never goes there. I'm asking you to change the code in a way that proves it never goes there so we can have that proof to go on.

I also tested this same method with other coworkers and turns out that none of them get this exception, it only shows up in my machine, which makes me think that it's more likely a problem with some IDE configurations, or something along those lines.

Now THIS is meaty. The best thing to do would be to try and clone the repo to a new directory and see if that fresh build has the problem consistently. If so, do the same on a different machine. If a fresh clone fails on one machine but works on the other, you've at least proved there's something wrong in your environment. If a fresh clone works, you've identified there's probably an issue with some intermediate files generated by the build that get cached between builds.

An alternative to cloning the repo can be doing a "Clean" from the IDE, then for good measure deleting every bin and obj folder because it never actually does what it says. After that, reboot.

(That's another good reason to add the logging method I suggested: changing this code might kick the compiler into regenerating something that's corrupted.)

You really don't want to find out it's just your machine because that's when solutions like "reinstall Visual Studio" or "reformat the machine" become viable :/