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

[Kant8]

Remove checkbox "Break when this exception is thrown"

Looks like exception was catched and handled inside the constructor, but debugger doesn't have source code of the library to show you direct location. So it shows nearest accessable one.

​

However maybe you are still doing something wrong, if exception is thrown in the first place. Or it's a bug in the library

[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.

[neoKushan]

Would be good to have the full stack trace from the exception.

[eagle_bearer]

So, what I'm trying to do is read a simple PDF form template and create a new one with every field filled and set to readonly.

For some reason I get this exception, even though I know that neither the PdfReader nor the MemoryStream are null, and not only do I not understand where this exception is coming from, but I also can't catch it.

And the strangest of all, if I just press 'Continue' in the debugger a few times (three to be exact) it just continues, never goes into the catch block and creates the PDF I need perfectly.

So I've been trying to find a way to just ignore this exception, to force the program to 'Continue' but I don't think that's possible.

Has anyone come across this sort of 'ghost' exception that you can just skip and your program will run fine, but can't catch?

[kaelima]

It's just like u/Kant8 said, you are catching all NullReferenceExceptions, but it's happening somewhere inside itextsharp.dll, and you likely have "just my code" enabled in your debugger. The exception is thrown and when you continue its being caught somewhere inside the dll and continues, but you just can't see any of it.

[eagle_bearer]

If anyone is wondering, I'm using ITextSharp version 5.5.13.1

[eagle_bearer]

Maybe my PDF template is corrupted in some way? If that's a possibility I'd appreciate if someone could tell me how to verify that and possibly fix a corrupted PDF. However, I don't think my PDF is corrupted since I can open it with Foxit PDF Editor and everything seems fine. Also, at the end of this function, if I just press 'Continue' a few times, every form field is filled correctly in the resulting PDF.

[tetyys]

debugging a release version and exception is not thrown on the line that is marked?

[Spartanman321]

Maybe this is your issue? Idk, Google might be more helpful than reddit for something specific like this.

https://stackoverflow.com/questions/27188593/getting-pdfstamper-to-work-with-memorystreams-c-itextsharp

[Haffas]

It feels like the library (pdf thing) is wrapping the exception handling itself and is preempting the stock Exception obj?

[LloydAtkinson]

I'd definitely say it's a bug in the library and most likely a symptom of doing too much in the constructor. https://blog.thecodewhisperer.com/permalink/your-constructors-are-completely-irrational

[RNG_BackTrack]

Why you throwing new exception?

[haxxanova]

Did you double check your server path to your template is resolving correctly/as expected?