If You're Lucky It Will Blow Up

by Nick Tuesday, March 27, 2007 8:49 PM

In my tenure as a software engineer, I've seen a lot of poorly written code, especially in my C++ days.  Pointer magic that had no business being compiled, and error handling that was slim to non-existent.  Even in the world of .NET, it's still possibly to write dangerous code:

   // Call a method may throw an exception
catch ( Exception ex )
   // Eat the exception
   System.Diagnostics.Debug.WriteLine( ex.Message );

How many times have you seen code like that?  Hell, sometimes I don't even see the Debug.WriteLine.  Sometimes they just eat the exception.  Exceptions aren't a bad thing.  In fact, having an exception occur is a good thing.  I still remember something my advisor said during a class talking about pointers at MSOE... "If you're lucky, it will blow up."

The worst errors that can occur are the ones that don't have outward signs.  Perhaps you did some bad pointer arithmetic, but instead of throwing an exception because you illegally accessed memory, it simply reads that memory and a counter equals 50 instead of 5.  Your program could appear to function perfectly, but will provide incorrect results.  Worse yet, when an symptom does finally appear... the symptom will so far away from the cause, that you may never find it.

Eating exceptions is about the closest you can come in .NET without trying really hard.  People are so afraid of seeing a box with that red X, that they eat them left and right without realizing that having an immediately failure that is easy to identify and fix is preferable to a bug that is impossible to track down.

Exceptions happen for a reason... and that reason should be taken seriously.  If you can write code to handle that exception in a catch block, then by all means do it.  But if your "exception handling" code simply boils down to logging it and continuing... do yourself a favor and rethrow that exception (or don't catch it at all) and put your program out of its' misery.  You'll thank me in the long run.

Why Case Insensitivity Blows

by Nick Thursday, March 22, 2007 7:54 PM

I ran into this problem at work today, which reminded me why case insensitive languages (like Visual Basic) suck.  Or if you prefer, I found a bug in a Microsoft tool.  I was using xsd.exe to generate a type safe class for an XML schema that I received from a company we do business with.  Instead of reproducing all the schema and code here, I'll boil it down to the simplest code which still reproduces the problem.  Let's say you have an XML schema that looks like this:

<?xml version="1.0" encoding="utf-8"?>
<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="Root">
        <xs:element name="Node">
              <xs:extension base="xs:string">
                <xs:attribute name="VALUE" type="xs:string" use="required" />

And here is an XML fragment which will obey this schema:

<?xml version="1.0" encoding="utf-8" ?>
  <Node VALUE="Hello">World</Node>

Pretty simple so far, right?  If you save that schema off as XmlDoc.xsd, and then run xsd against it using the following command line options:

xsd XmlDoc.xsd /c /f /l:VB

You will get the following class definition as output:

' <auto-generated>
'     This code was generated by a tool.
'     Runtime Version:2.0.50727.42
'     Changes to this file may cause incorrect behavior and will be lost if
'     the code is regenerated.
' </auto-generated>

Option Strict Off
Option Explicit On

Imports System.Xml.Serialization

'This source code was auto-generated by xsd, Version=2.0.50727.42.

<System.CodeDom.Compiler.GeneratedCodeAttribute("xsd", "2.0.50727.42"),  _
 System.SerializableAttribute(),  _
 System.Diagnostics.DebuggerStepThroughAttribute(),  _
 System.ComponentModel.DesignerCategoryAttribute("code"),  _
 System.Xml.Serialization.XmlTypeAttribute(AnonymousType:=true),  _
 System.Xml.Serialization.XmlRootAttribute([Namespace]:="", IsNullable:=false)>  _
Partial Public Class Root
    Public Node As RootNode
End Class

<System.CodeDom.Compiler.GeneratedCodeAttribute("xsd", "2.0.50727.42"),  _
 System.SerializableAttribute(),  _
 System.Diagnostics.DebuggerStepThroughAttribute(),  _
 System.ComponentModel.DesignerCategoryAttribute("code"),  _
 System.Xml.Serialization.XmlTypeAttribute(AnonymousType:=true)>  _
Partial Public Class RootNode
    <System.Xml.Serialization.XmlAttributeAttribute()>  _
    Public VALUE As String
    <System.Xml.Serialization.XmlTextAttribute()>  _
    Public Value As String
End Class

What you'll notice is that that RootNode class has two fields named Value.  One of them is upper case (as it was in the schema declaration), and the other is Pascal case.  This second one is marked with the XmlTextAttribute, meaning that it is the property which represents the Element Text value (in my sample XML document it would be equal to "World" while VALUE would equal "Hello").

If we were doing this in C#, all would be fine and dandy since it's case sensitve.  However, with Visual Basic, this generates a compiler error.  In the case of my 1300 line schema file at work, I had to modify 42 different fields that met this pattern.  And because I had to hand modify an auto-generated file, there is no way that I can automate this generation as part of a build process... which sucks if the schema ever changes.

Wouldn't it be nice if xsd.exe were actually smart enough to verify that there was no name collision with the Value field before it used it, and chose an alternate name... or perhaps had a command line argument were you could provide a name to override the default?

What Do You Mean You've Never Seen It?

by Nick Tuesday, March 20, 2007 9:29 PM

It always amazes me when I run into people in the software profession that haven't seen Office Space.  So I was totally shocked when I found out that not only has the person sitting to my right never seen it, but neither has the person on my left at my new client.  It's required viewing!  I immediately had to bring in my copy of the DVD for them in order to rectify the situation.  I also always make sure to warn anyone who hasn't seen it, that it's not a comedy.  It's a documentary.

Give Away Your Old Computers

by Nick Sunday, March 18, 2007 12:35 PM

I blogged about this about two months ago, but it bears repeating.  Developers always make sure to have the best computers, and we upgrade often.  After all... it's our job to stay up to date, and as geeks we always like to have the best toys.  But what do you do with your old machines once you've decided it's too out of date for you?  Odds are that even though it's out of date to you, it's still a pretty good machine for someone else.

I just did this with my old laptop, and I've done it a few times before.  Don't sell your old computers on eBay.  Find someone who needs a computer and can't afford one, and give it away.  It won't take you long to format the drive and put a fresh install of Windows on it.  Now your computer can have a good hardy second life.  Odds are that it will have a more useful life than with someone who buys it on eBay just to scrap it for parts.

In one case, an old computer I gave away was lucky enough to have a third life.  After the person I gave it to was able to get something better, she asked me whether I wanted it back.  I laughed, and told her to find someone to give it away to.  And so it went on to serve yet another master to someone who needed a computer at a key time in her life.  My only regret at the time was not having something better to give away myself so she could have something better than a third generation hand me down.

It feels good to do, and it's something that we as developers can easily do.

Funny Code of the Day

by Nick Monday, March 12, 2007 7:09 PM

If vdResult.IsValid = True Then

I have no idea what you'd want to do if that happened.

It's Like Watching a Car Accident

by Nick Friday, March 09, 2007 7:10 PM

You just can't stop watching... even if it is 10 minutes long.  So let me get this straight... voice recognition is supposed to make things easier... right?

Via Omar.

About Me

Nick Schweitzer Nick Schweitzer
Wauwatosa, WI

Contact Me
I'm a Software Consultant in the Milwaukee area. Among various geeky pursuits, I'm also an amateur triathlete, and enjoy rock climbing. I also like to think I'm a political pundit. ... Full Bio

Community Involvement



Flickr Photos

This is a Flickr badge showing public photos and videos from Nick_Schweitzer. Make your own badge here.

Standard Disclaimers

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2017 Nick Schweitzer