NeuralJack Posted February 23, 2007 Posted February 23, 2007 I have been told a few times that the best thing to do when programming is to try to avoid raising any and all potential errors, instead of using the raised errors themselves to figure out what to do next. At least, this is what I took from it. So, I'm wondering if you guys think this should be done during simple math calculations too.. in order to avoid things like overflow? Do you check each and every math operation you do before you do it, or do you let the try/catch handle an error the way you want it? Simple Case: You want to add 2 user entered Integers together. If there is an overflow set the Total to Maximum Int 64 Value. Addition Method 1 (Use Try/Catch) Dim Int1 As Int64 = 'User enters a value Dim Int2 As Int64 = 'User enters a value Dim Total As Int64 Try Total = Int1 + Int2 Catch ex1 as System.OverflowException Total = Int64.MaxValue End Try Addition Method 2 (Check for overflow yourself before addition, to avoid raising errors) Private Sub AddThis() Dim Int1 As Int64 = 'User enters a value Dim Int2 As Int64 = 'User enters a value Dim Total As Int64 If AdditionIsOK() Total = Int1 + Int2 Else Total = int64.MaxValue End If End Sub Private Function AdditionIsOK(ByVal Int1 as int64,ByVal Int2 as int64) as boolean If Int1 >= 0 And Int2 >= 0 Then 'Both Numbers are Positive Dim MaxAllowedInt2 as int64 = Int64.MaxValue - Int1 If Int2 <= MaxAllowedInt2 Return True EndIf ElseIf ... 'Code for when Both Numbers are Negative ElseIf ... 'Code for when Int1 is Negative and Int2 is Positive ElseIf ... 'Code for when Int2 is Negative and Int1 is Positive EndIf Return False End Function I don't know, Method 2 just seems a little excessive to me. But you guys have slapped me straight many times and I'm beggin for more. Let me know what you think. Quote Currently Using: Visual Basic.Net 2005, .Net Framework 2.0
mskeel Posted February 23, 2007 Posted February 23, 2007 Personally, I'd go with method 1 unless it is highly probable that overflows occur a majority of the time. In my experience, an overflow is a rare event and only occurs under exceptional circumstances. It's not really about trying to prevent all errors and never throwing an exception. The basic idea is that you want to capture the likely errors and reserve exceptions for exceptional errors, or things that don't happen that often. Quote
NeuralJack Posted February 23, 2007 Author Posted February 23, 2007 Ok thanks, I agree. Yes, overflows for this project should also be rare. I'll try to stick with the mentality of avoiding the use of raised errors as tools(in try/catch statements), unless the chance of a raised error is extremely low. Quote Currently Using: Visual Basic.Net 2005, .Net Framework 2.0
Administrators PlausiblyDamp Posted February 23, 2007 Administrators Posted February 23, 2007 (edited) The actual performance hit of an exception being thrown isn't that great in a release build anyway (there still is one so excessive exceptions need to be avoided) however the second example of yours probably puts it's own performance overheads on and increases the code to maintain while decreasing the readability... I am a big believer in the phrase "Premature optimization is the root of all evil." if the performance hit of writing cleaner more readable and maintainable code is sufficient to be a problem then I will look at alternatives.... Edited February 24, 2007 by PlausiblyDamp Quote Posting Guidelines FAQ Post Formatting Intellectuals solve problems; geniuses prevent them. -- Albert Einstein
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.