I know we've discussed this in the past, but it's always worth visiting Visual Basic's error handling approach. Not Visual Basic .Net, which adopts the common try/catch approach, but classic VB, which had two options.

The first was On Error Goto LABEL, which lets you jump to an error handler using a goto. The second was On Error Resume Next which does nothing when you get an error, leaving you to check return codes to see if there were any errors.

A depressing amount of code used On Error Resume Next but also didn't check error codes.

Awhile back, Joshua was the last survivor of a round of layoffs. He went from being part of a team to being the only developer supporting a VB .Net application handling a few hundred thousand transactions a day.

It was a bit of a mess, as things go. The B2B application was used by a dozen or so customers, who all needed to exchange data via XML. The XML generation code was copied and pasted for each customer, giving them each a distinct and unique code path, despite them all receiving the same XML data. This meant that what would have been a few thousand lines of reusable code ballooned out to well over 25kloc.

But the original developer also clearly loved On Error Resume Next, because this is how they handled errors:

Try
        xmlDoc.LoadXml(MyBuffer)
Catch ex As Exception
        MajorError = True
End Try

MajorError is a global variable. It's checked at various points in the code, but as you can see, it's just a boolean. It doesn't convey any exception information about what went wrong, just that an error occurred. Which sure, for your end users, you sometimes just say, "An error occurred," because there's no point in explaining to them a problem they can't fix. But for your developers and support staff, having some idea of what went wrong is helpful.

[Advertisement] Keep the plebs out of prod. Restrict NuGet feed privileges with ProGet. Learn more.