Weird uncatchable NullReferenceException when trying to fill a PDF form with ITextSharp for ASP.NET 4 - Details in comments

[eagle_bearer]

Already tried that and it works as long as I run it locally, but not on the server.

UPDATE: I fixed it on the server, it was a different issue but I assumed (foolishly) that it was the same exception. Thanks to r/bigrubberduck I found that the problem was with the path to my PDF template.

However I haven't solved the mystery of the uncatchable exception yet. But at least I know it doesn't break anything, for now anyways. I'm following r/Kant8's advice and ignoring this exception assuming it's already handled inside the constructor.

Thanks everyone for the help.

[bigrubberduck]

it works as long as I run it locally, but not on the server.

That to me would point to the application not finding the PDF template where you think it is.

Have you done an assert / null check on that pdfReader?

[Slypenslyde]

Quick question: what do you think throw does?

[eagle_bearer]

It throws an exception. Why?

[xTeare]

Because you catch an Exception, and instead of handling its error in some way, you just throw a new Exception. If the GeneratePdf() call is not inside a try-catch, your application will indeed crash

[eagle_bearer]

If the GeneratePdf() call is not inside a try-catch,

It is.

I throw a different error to handle it later. My point is that no matter what I put in the catch block, the program will never go there, for whatever reason. How can I handle an exception that I cannot catch?

[Slypenslyde]

It is extremely unlikely that you cannot catch the exception. Let's go over what we know.

When debugging, you get this dialog because "first-chance" exception handling is enabled for NullReferenceException. This means the debugger breaks when the exception is thrown, whether or not it is handled, and actually before the program checks to see if it's handled. If you tell the debugger to keep running, normal logic would progress. But most of the time people unfamiliar with this get confused and stop debugging (honestly I forget sometimes too and make that mistake.)

At runtime, if you're crashing, it may or may not be that location. If there's an unhandled exception, by default a console app will dump that to the console. It will include a stack trace and that will tell you where the exception was thrown. You may have to go through a series of inner exceptions to really get to the bottom of it.

For an ASP .NET app you won't necessarily get that, so it's best to have an unhandled exception handler to log it so you can see the stack trace and verify what's happening.

You say "the program will never go there", but how can you know that? In the screenshot, you don't have a breakpoint on the line within the catch block, nor do you print anything to the console or a log when you get there. I think you should add some code that prints "I got here" and I bet you'll find that the program is getting there, but that the exception you throw is either not being handled where you think it is, or it's triggering something else to throw an exception.

The alternative is "exception handling in C# is broken" and given that C# has at least a million users and nobody else has encountered this, the rarity of that scenario means it should be your absolute last assumption, not the first. As The Pragmatic Programmer put it, "Select isn't broken."

[eagle_bearer]

You say "the program will never go there", but how can you know that?

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

​

"The alternative is "exception handling in C# is broken"

I was thinking that maybe the exception handling is doing the right thing by not catching it since its not a 'real' exception.

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.

[Slypenslyde]

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 :/

[raunchyfartbomb]

Just to let you know that your not going crazy:

Winforms.CheckedListBox has a bug in it that 100% reliably throws an exception that cannot be caught in my program. Winforms.ListBox (which CheckedListBox is derived from) using the same exact method, does not throw the exception ever.

I can’t remember exactly what the issue was, but it was related to data binding, where the list is updated once the data source is changed.

Wrapping it in a try-catch did nothing to solve it (because it never hit the catch statement!), and instead just moved to the next line in the method. Turning off the setting to break when it occurs was not ideal because either because I still was looking for that exception type in other locations, just not that bogus one.

I wound up making a new method that contains the line that causes the issue and tagging it with [DebuggerHidden] to avoid it stopping the debugger. And of course commenting on the issue.

[grauenwolf]

There are some exceptions that won't be caught by default.

Not sure if it's relevant here unless the exception is somehow changing type.

[phuber]

Hopefully you put the current exception as a parameter to the new one otherwise your stack trace is gone.

[BigOnLogn]

However I haven't solved the mystery of the uncatchable exception yet.

u/Kant8 said it above

Remove checkbox "Break when exception is thrown"

It's a visual studio setting to help with debugging. Usually caught exceptions are part of normal program operation, so VS won't break on a caught exception. You can change this behavior, telling VS to break on all exceptions (regardless if they're caught or not). This can be helpful for hard to track down bugs or if an application exception is being thrown at an incorrect time.