Crash Responsibly

Kevin, I suppose you do what MSFT did in the screenshot above – you ask permission from the user and explain what it’s for.

You can actually sign up with Microsoft to get automated error reports back from them, too:

http://msdn.microsoft.com/en-us/isv/bb190483.aspx

All you need is a $400 cert.

Our application crashes to pretty bad error screens, but is designed so that in almost all cases (sometimes heap corruption kills the .NET framework !?!) the application will be able to save its data in case of a catastrophic error.

thanks for sharing about ELMAH

never knew there was a framework entirely for exceptions before

do you keep a tools list also? like your recommended reading list but instead for the tools you use? would really appreciate that

love your blog ^^"

Jeff, I’m wondering if you’ve seen DamnIT (http://damnit.jupiterit.com). It automatically warns you if your page errors in IE or FF. It also groups most common errors.

crash early

When you hit a unrecoverable error, the only suggestion i have found useful is to “crash early”. The more you delay and try to “fix” the thing the more havoc you cause.

~TH

Personally I prefer to blame my users whenever possible, of course it helps that our employees are forced to use my application! :wink:

Opera has a pretty good disaster recovery tool, it let’s the browser save the current tabs/windows open and if Opera crashes when you boot it up again it asks if you want to load those tabs again.

hoffmann both internet explorer and firefox also do this

Same goes for firefox. And with firefox beta 5, It is used more then I like. A lot more!

Just tried out ELMAH it seems to work great although I haven’t finished experimenting fully yet, I don’t know if it may catch things I don’t consider an error such part of my site requires a user to be in certain active directory groups on our network this is technically an error but I don’t need to know about it. It currently redirects to an access denied page.

@Owen: how exactly does the OS pull the rug on you just because you’re using c++? Set up some seh and you handle the critical errors yourself, which gives you the freedom to save any and all data you want and display whatever crash-screen to your users. That shouldn’t be much of a problem in c++ unless I’m missing something.

Coming from asm, though, some advice: TEST the values you use for pointers. If you blindly accept whatever value you get back from system calls, you’re in for a world of pain.

Regards
Fake

I think Visual Studio has the best variety of crash symptoms - my favourite is when it just vanishes usually when you get to the critical point in a debug session. Others I experience daily include the indefinite hang, indefinite hang followed by losing all your work (with the ‘oops something went wrong dialog’) - usually occurs when switching from Debug to Release or vv., hang followed by crash followed by corrupted csproj files, OOM in intellisense, the list just goes on and on…!

@Jherico, while pointer de-referencing is a little off-topic, it’s a little arrogant to say that well, you should only need to ever check on creation and your code should know where it’s at.

Inside a class and it’s private methods, you shouldn’t need to continually check. However it’s the public entry-point to any object that is a source of errors.

No matter how smart you are, if you are working in a team, your code will be reused in some way you didn’t anticipate (another developer perhaps). I typically look at it from the argument checking point of view, where if the code below assumes the pointer (or reference in my case) isn’t null, and I get a null pointer, the code’s going to blow up anyways. I’m making the code more explicit and making sure that somebody doesn’t think it’s my code that’s bad. Null isn’t an error, it’s an object state. In a way, NullableT in .net is proof that null is a first class citizen and needs to be explicitly accounted for.

in …
void foo( MyStack stack )
{
//if( foo == null ) { throw new ArgumentNullException(“stack”, “stack passed can not be null”);}

stack.Push(100);
}

what’s a better message
"Object reference not set to an instance of an object"
or
"System.ArgumentNullException: stack passed can not be null"

It really goes back to the concept of Fail Early and Fail Often. This way, in testing and coding, you catch more errors because you’re writing the contract into the class explicitly.

PS I’ll also make a case for the Null Object Pattern here, because it’s incredibly useful when applied correctly and cuts down on a ridiculous number of null checks.

@Omar Abid: do you see any spam here?

Yes, the captcha is always “orange”. That’s by design. It’s enough to stop spammers.

@Owen, Steve:

To catch unhandled SEH errors in Windows, call SetUnhandledExceptionFilter. To catch unhandled errors in .NET, including Windows Forms, add a handler for the AppDomain.UnhandledException event. Both setups will catch all unhandled exceptions on any thread in the process.

The .NET handler works in all versions of the full .NET Framework, and in version 2.0 and later of the .NET Compact Framework. Generally, use:

AppDomain.CurrentDomain.UnhandledException +=
new UnhandledExceptionEventHandler( methodName );

The current philosophy on software performance and stability is pretty much like this: If you have fewer than two cores or less than two gigs of ram, you shouldn’t even be complaining about poor performance or crashes. Go get yourself a new computer.

The rest of us just get left behind.

@Tom: “Well, let me see, what could you do to solve that problem…
Hmmm…
Every time you dereference a pointer you should check if it’s null. Every Time You Dereference A Pointer You Should Check If It’s Null. EVERY TIME YOU DEREFERENCE A POINTER YOU SHOULD CHECK IF IT’S NULL.”

While that might be good advice, it doesn’t really help with the question about how to implement the error handling for a NULL pointer dereference, not to mention that not all bad pointers are NULL pointers. Your advice is pretty much like saying, “handle your errors by not having them in the first place”. Which is great, but it doesn’t help handle the defect that does slip through.

Crashes are not everything I hate in MS products. There are many small annoyances that are really small but very annoying.

Meh, I just write code that doesn’t crash.

Jheriko: “The first comment is gold considering that C++ has exceptions.”

Which doesn’t help you catch null pointer dereferences since they don’t throw C++ exceptions. In fact, they produce undefined behavior. On the DeathStation 9000, the OS catches them and initiates automatic shredding of the user’s hard drives.

To deal with null pointer dereferences requires platform-specific code: SEH on Windows, catching SIGSEG on POSIX, and who knows what else on Weird Embedded System #302.