Discussion on:

Tracking down a tricky null reference bug

They introduce unusual code paths and weird zones in your code. A monad is a much better model. Unfortunately, that could take quite a bit of work to implement in C#.

... it's also questionable that the API for Exception allows you to do things that can throw exceptions... it's a TOTALLY untestable piece of code.

J.Ja

Just let the bloody thing write its **** to the event log by itself.

System exceptions (divide by zero, null reference, etc) should be handled by system. Handle that stuff by yourself only when you absolutely have to- which is about as common as a necessity of using goto statement. The "catch" block is a breeding ground for the nastiest of bugs.

for last ditch catching, if you have to (say if you want it logged to file and/or the event viewer.
Is Applications OnCurrentDomainUnhandledException event.
But other than that never ever ever trap exceptions you can't deal with, is rule one.

I do my best to stay out of global.asax, so that never occurred to me!

J.Ja

... is that you don't always have access to it. You need to create an event source... which requires elevated permissions... to write to the log. In this particular case (I had so little access that I couldn't get a debugger on, remember?) I wasn't able to do that either.

J.Ja

The way we addressed this, was to setup a Source for us a ISP, then sub sources based on the various applications, and one called general.
Code tries to find one for the current running application, if not it drops to General.
Getting them in (or changing them was PIA though).
Had to write an app that ran unelevated and reported the event sources. If they were different, then request elevated access (Have admin, UAC, log ion as Admin blah blah ) and then fix them and call that as prerequisite of the install. Took a while to get right that, supporting everything from XP to Win 7, Win2003 to to 2008R" and terminial services..

Quite why MS forced this extreme coupling with the registry I've yet to figure out. Certainly isn't the way I'd have approached it, logging some where to me is much more important than logging to exactly the right place and conking out if it doesn't exist. UI centric design again.
Even if you do all the work to set up the event sources, there's nowt to stop someone with admin access deleteing it from the registry and frying your carefully prepared algorithm. So you end up getting an error you couldn't log something, and hope the thing you were trying to log is in it, otherwise you can't investigate the real fault.

It totally boggles my mind that the Event Log would need elevated access to create an Event Source, especially since once it is created, there is nothing stopping you from using it...

J.Ja

and one of the leaves is the Security event source. A moment's thought would have come up with the viability of say UserEvent Sources and System EventSources. but as usual user versus system privileges skipped right past MS's pointy heads.

> I had so little access that I couldn't get a debugger on, remember?

Establishing the local debugging environment and trying to replicate bug there is generally less frustrating than debugging "blindly", the way we used to do it when I way young. I hated the meditation over program printed on paper so much I wrote symbolic debugger myself once.

Why would you need to program without debugger anyway? If you are troubleshooting something that can't be replicated in developing environment, you need access to certain things, and that't it. The people in charge of production environment will just have to babysit you during the process, there is no other reasonable way to do it.

It's a very long story, let's just say that if I *could* have a debugger attaching to things, I *would*, but Microsoft has made it very difficult to debug the "plugins" for their CRM product...

J.Ja

Say no more.

As far as I'm concerned, there's one word answer to this: Drupal.

We recently tried to figure out why something wasn't working on a partner's machine. Several things stopped us from being able to debug properly:
1. Inability to reproduce the issue elsewhere. This meant we had to work on this machine.
2. No debuggers or other dev tools installed.
3. Not allowed to install additional software.
4. Time constraints.

This was for a stand-alone application (not a website or something like that) and a large portion of it is customizable and written in JScript.

Ex.StackTrace will serve you better, as the inner exception chain is theoretically infinite.
Also if you use Fx Cop, it would have jibbed at that code and at least forced a null check...

... and it wasn't giving me what I wanted. Good point on StyleCop. Interesting, ReSharper didn't pick it up as far as I can tell...

J.Ja

ex.printStackTrace() would have given you all of the information you needed to debug the issue. The problem here is that ex.getMessage() or ex.getLocalMessage() can be null and you need to allow for that in all cases. It all comes down to the code throwing the Exception does not have to set the message content. Remember that are Exception constructors which do not include a message.

I had already tried StackTrace, and I didn't get what I was looking for from it.

J.Ja

Something breaking the exception chain.

Try
...
Catch (Exception ex)
...
throw ex;

is the classic for that.

Should be just throw, or throw new Exception("Fred",ex)