Hi
Of course, you can't be sure there will be NO bugs, but you can plan for unexpected 'exceptions'.
- Do extensive testing in the Debug mode where breakpoints and single stepping are key. During this stage, I would normally comment out all Try....Catch statements so that any issues will crash the programme and show where the crash occurred.
- For release to your unsuspecting public, uncomment any Try.....Catch statements, and perhaps add more of them - ENSURE none of them have empty Catch blocks - either write the exception details to a log file and/or notify the user via a MessageBox (where you can offer profuse apologies for your poor coding)
- Ask the Users to report any issues not highlighted by the MessageBox(s) so that you can try to fix.
- Check any log files where you would have written complete information of where/why the exception occurred, and of course, written any relevant user/variable values that may be important. eg the user entered a letter caracter into a textbox where a number as expected! I mean, can your users not rrad your mind and understand that where it asked for an 'age', that the input 'old' just won't do!
- Pay out the multi million dollars for the untold damage your code has done to a multi national business.
The better way is to thoroughly test your code using all the stupid inputs possible and with expected files not being there and expected file paths not being found and folders missing and malformed data and all the possible date formats possible and .......................... etc.
For example, I found one of the most common user input problems was entering non-numerical characters into a textbox where a numeric value was expected. My approach to that was that EVERY user input where a number was expected war run through a Function where an Integer.TryParse (or Double.tryParse) would ensure my code did get a numeric value (of ZERO if not a numeric input) and would likely just cause an unexpected reult rather than a crash. Maybe, setting up a custom control textbox where only valid numeric data can be entered etc ........... Of couse, where other controls (such as DataTables/DataGridViews are being used, the the same Functions can be a big advantage in some circumstances to avoid mathematicall exceptions, but for these, there are many other considerations needed)
Most of all, you need to have your thinking cap on while creating/debugging your code .......................
Good luck with all that .....................
Example Functions for Integer and Double values.
Function GetDouble(s As String) As Double
Dim v As Double = 0.00
Double.TryParse(s, v)
Return v
End Function
Function GetInteger(s As String) As Integer
Dim v As Integer = 0
If Integer.TryParse(s, v) Then Return v
Return v
End Function