Home/ Questions/Q 3390950
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-18T03:45:00+00:00

So I never got into detailed error processing too much when I played in

  • 0

So I never got into detailed error processing too much when I played in VBA/VB6 a lot. Mostly then, if you ran into a user error (such as some input of theirs failing a validation test of some kind), you popped a MsgBox() with some error information and the critical (or warning) icon, and safely aborted out of the code and hope they got a clue.

In .NET, my reading basically points to exceptions as the end-all in error handling. It looks to me that if you know a spot of code where a user can screw up, you’re supposed to catch it with either try…catch blocks (for things like data conversions), or standard if…the…else constructs for other things, and then throw a new exception if needed.

Isn’t throwing an exception essentially a forced crash of a program in a sense (granted, you get the option of continuing)? Or are exceptions geared specifically for things like data conversion errors and other “things that shouldn’t happen”, and resume use of MsgBox() and friends for minor user screwups?

Consider the case of where you have a TextBox that is only supposed to accept numeric data (or heck, just a specific set of characters). Barring some other trick that lets you restrict that field (let’s just assume it’s freeform, programatically), it would seem a bit of a waste to throw new exceptions everytime they type in an invalid character, or even if the error checking doesn’t happen until they press a submit button (like on a webpage). Popping a MsgBox() seems more sane in that case.

So what’s the straight dope on exceptions and throwing new ones on user errors? How about if your program also exposes a programmatic framework? Bad usage of one of the programmatic functions definitely seems like new exception territory to me.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Exceptions in .NET certainly are available for bad entry, not just the things that should never go wrong. In any case, you shouldn’t be letting unhanded exceptions get to the user.

    You’re probably going to displaying a MsgBox whether you ‘testing’ the input, or letting the framework detect an exception, so it doesn’t make a huge amount of difference. Seeing as exceptions are generally slow, you should probably use ‘if’ statements to capture the obvious validation errors, and rely on exceptions to capture the more obscure scenarios.

    • 0