clunk....help.

Hi everyone,
I do believe i require some assistance in a program I'm creating for an assignment. i have it working, all except for the Try-catch statement. it works, it highlights the error, yet it keeps on crashing the program when i click the ok button. it also highlights the
dblCost = Convert.ToDouble(txtAdults.Text) * 40 + Convert.ToDouble(txtChildren.Text) * 20 of the second portion of code as the error whenever a non-numerical value is entered. Its quite frustrating and I do wish to keep the frontal portion of my skull intact, so could someone please help.

Code:

---

        Dim dblCost As Double

        Try
            dblCost = Convert.ToDouble(txtAdults.Text) * 40 + Convert.ToDouble(txtChildren.Text) * 20
        Catch exception As System.Exception
            MessageBox.Show("Error, please input a number(s) greater than 0", "ERROR!", MessageBoxButtons.OK)
            Clear_Text()
        End Try


dblCost = Convert.ToDouble(txtAdults.Text) * 40 + Convert.ToDouble(txtChildren.Text) * 20
txtAmountDue.Text = "The total amount due is R" + dblCost.ToString

---

correct... in design time... that's the way it works... If you press Ctrl-Alt-E ... you can change how errors are handled... try clearing the left chckbox of the .... second item on the list "Common Language Runtime Exceptions" ... when it's checked, it throws errors, even when in a Try.... it's useful for making sure things are running smoothly.

Instead of Convert.ToDouble .... look at Double.TryParse method instead... and instead of using an exception to catch data entry errors, prevent the errors in the first place, or check the values of the text boxes first. Exceptions are expensive and shouldn't be used for data processing or validation.... what you're doing is what I call defensive programming.... try using offensive programing instead... if there's a possibility that non-numerics can be entered... check for it... be proactive, not reactive.

-tg

thank you for the advice. i'm trying to make it crash proof, so that if a letter is entered, or nothing is entered at all, it will bring up the error with the ok, clear everything and then reset it all to its default start state. it all works upto the stage where it returns from the error box to the program. thats where it crashes. I'm not entirely sure on how to use the double.TryParse, does it replace the first dblCost = Convert.ToDouble? because I tried that and it underlined it.

I know you're trying to make it crash proof... but what you're doing is still allowing the crash to happen....

As for how tryparse works, did you look it up in MSDN?.

-tg

vb Code:

dim dblValue as double = 0
if double.tryparse(textbox1.text, dblValue) then
   'textbox1.text was successfully parsed as a double
   'dblValue contains the value
end if

thanks everyone for all your help, i finaly have it working properly, turns out that it was the
dblCost = Convert.ToDouble(txtAdults.Text) * 40 + Convert.ToDouble(txtChildren.Text) * 20
txtAmountDue.Text = "The total amount due is R" + dblCost.ToString

that was in the wrong place and was causing the crash.

Just for clarification: Try...Catch blocks are only expensive if an exception is actually thrown. They cost nothing if no exception is thrown. This means that you should not use them to catch things that you can test for, as you have seen, but go right ahead and use them for things that you can't test for. Those are truly exceptional situations, and the exceptions need to be trapped.

I'd like to point out that programs crash in order to explicitly prevent false results or erratic behaviour and not because it is hard to make uncrashable software.

I personally don't mind that a user is not asked if he still wants to transfer 1 0ah 000 € and instead is forced to start over if the developer hasn't provided input checking.

Half - could you try that again.... that doesn't make a lot of sense.

-tg

sure

In my line of work some drill bits are designed to break if they suddenly sink more than a set number of millimeters. So even if I jam such a thing into Twisted_Bobbay's frontal portion of the skull, the injuries won't be serious.

Electrical fuses are another fine example. A blackout is better than a burning block. We are practically surrounded by predetermined breaking points.

How ever, would you not agree that PREVENTING the injury to Twisted_Bobby's skull would be ideal, rather than to find out after the fact that it wasn't such a hot idea? What you're proposing is that it would be acceptable for my car key to snap off in the lock simply because I placed it into the front door of my house. Wouldn't you agree that in this case, it would be more acceptable that the lock on the front door simply NOT accept the invalid input of a car key in the first place?

-tg

Ah, yes. The many philosophys around exception handling. Personally, I want every situation handled, and I use the error messages to make sarcastic remarks to the user. I can tell when somebody has screwed up when they start laughing. I went too far with it one time, and nobody would use my program until they had spent the first hour reading the messages that were provided by one sequence of buttons.

Yes, of course I would agree. All I am saying is that crashing is an intended last resort convention implemented by most OS providers to shelter users from inexperienced developers and not some physical / electromagnetic necessity. Most of you here know what you are doing but when I had the brilliant idea to ignore errors in my first calculator with that cool Try / Catch ...well I'm glad nobody is using it.

What if you are not that good yet? Allow wrong input and let your program wreak havoc or keep it crashing until you take care of the problem...

The car key analogy is a good one in the context but I am sure there are security locks that break the first time you insert a wrong key.