programming languages
If you’re waiting around for users to tell you about problems with your website or application, you’re only seeing a tiny fraction of all the problems that are actually occurring. The proverbial tip of the iceberg. Also, if this is the case, I’m sorry to be the
programming languages
I’ve seen this kind of code a lot recently: try { int i = 0; int x = 0; Console.WriteLine(i / x); } catch (Exception ex) { Console.WriteLine(ex.Message); } This results in the following output: Attempted to divide by zero. Unless there’s some compelling reason you need an ultra-terse version
guids
Do you remember the scene from the movie Full Metal Jacket where the marines recite the USMC creed? It’s a little known fact, but programmers have a similar creed: This is my GUID. There are many like it but this one is mine. My GUID is my best friend.
c#
In .NET 1.1, TryParse is only available for the Double datatype. Version 2.0 of the framework extends TryParse to all the basic datatypes. Why do we care? Performance. Parse throws an exception if the conversion from a string to the specified datatype fails, whereas TryParse explicitly avoids throwing
.net
I recently posted a question about console apps and AppDomain.CurrentDomain.UnhandledException – specifically, why doesn’t it work as described in the MSDN documentation? I even filed an official bug report on this. I guess it worked, because Microsoft’s Jonathan Keljo was kind enough to explain this behavior in
.net framework
This one has me stumped. I’d swear this behaved differently prior to .NET 1.1 service pack 1 (and/or XP SP2), but I can’t prove it. As reported by a CodeProject reader, you’ll get the standard .NET crash dialog in a console app, even if you’
windows forms
In a previous post, I mentioned the old VB6 trick of deferring form work until the Form.Paint event in order to provide a (seemingly) responsive interface to the user. Well, in the .NET world there’s one strange side effect when you do this. Let’s say you had
.net framework
In response to my previous post decrying the lack of a master list of Exception classes for .NET, a helpful reader pointed out a clever little utility buried in the .NET SDK: Program FilesMicrosoft Visual Studio .NET 2003SDKv1.1Binwincv.exe Wincv works well, but it doesn’t allow me to
exception handling
I find myself throwing plain old System.Exception far too often. If only I had a complete reference of the many default Exception classes Microsoft provides, like the one Chris Sully provides in his article. That’s good as a starting point, but I don’t see things like System.
.net
In a recent entry, I bemoaned the lack of good global error handling options for .NET Web Services. By “good” I mean “easy,” like the Application_Error event in Global.asax for ASP.NET websites. I have a pretty solid web-oriented generic unhandled exception class, which is documented in my
asp.net
I just posted a new article to CodeProject, User Friendly ASP.NET Exception Handling. I casually mentioned in the original article that I didn’t think a global unhandled exception management class designed for WinForms and console apps was appropriate for ASP.NET apps, and that I had a separate-but-equal
exception handling
There’s a bit more subtlety to rethrowing exceptions than most developers realize. Although this topic is covered very nicely at The .NET Guy blog, here’s another example: Try session = smgr.getSession(_strDocbaseName) Catch ex As Exception If ex.Message.IndexOf("authentication failed") > 0 Then Throw