Category: Error Handling

Joey D’Antoni shares some thoughts on error messages:

I’ve been working in technology for entirely too long—but one of the first, and most important lessons I learned was try to identify the correct error message, in the right log file, and then it can be generally trivial to resolve that error message. The challenge to forever and ever always has been “finding the right error message”, as what typically happens is that once there is one failure in a computer program, there is a series of cascading errors, which makes it harder to identify the right error message that you need to copy and paste into google/stack overflow/chatgpt/copilot.

Read on for more. I think it’s easy for us to rag on bad error messages, though even opaque error codes can still be reasonable if there’s a comprehensive guide. This was a classic problem with blue screens: oh, I have an error code 0x2378f83f. So what does 0x2378f83f mean? Dunno, nobody else on the internet has apparently ever had that code. And Joey also brings up my favorite error message to rag on: “String or binary data would be truncated.” Sadly, although they did finally add column name and message text to the error, they never fixed the most galling mistake in that error message: the passive voice.

Steve Stedman handles an error:

SQL Server uses error severity levels to indicate the nature and seriousness of an error. These severity levels range from 0 to 25, with each level indicating a different type of issue, from informational messages to catastrophic failures. In this post, we’ll focus on severity levels 19 through 25, which are typically the most critical errors that can occur in SQL Server.

Fortunately, given how devastating they are, severity level 21 and higher are extremely rare in my experience.