Comment On Writing Bugfree software

MUAHAHAHAHAHAHAHAHA, STOP! Make the bad man STOP! My ribs HURT!!!!!!!!

Good idea, I'm going to develop a utility that wraps every line in all of my code in try-catch blocks.

man that is nucking futz.

IMHO, the only thing that's wrong with the code is that it's swallowing the exceptions.

If each of the assignments can throw, you need to wrap each of them in a try/catch.

If you're willing to play fast and loose with the internal state of the object, then you can wrap the entire block, but you don't know what's happening inside the various txtXxx structures.

Why? There are only two exceptions that could possibly be thrown here: A NullReferenceException if one of the controls is not instantiated (most likely won't occur), and an OutOfMemoryException if there isn't enough memory for the copied "Trimmed" string (most likely won't occur).

This code makes my tongue hurt.

hey, not to mention there is nothing in the Catch block, so, all it will do is sillently fail and go on...

If you had all in one block, if one failed, the next would not be executed right? in this case, not that bad code... but its swallowing the exceptions as if there was no tomorrow.

Larry,

There is absolutely no reason these statements should throw an error. Each of these text boxes should ALWAYS exist. If they don't, an error will occur earlier and you need to know why they don't exist, since they are members. Since the developer is swallowing exceptions, you'll never know. Trimming the .Text property should always work since its a string.

If you are going to code this way, you might as well put a Try...Catch around any line that does a string manipulation or assignment using a control or other object. And watch your performance CRAWL....

-Craig
The Submitter

YAY I GOT TRY CATCH...YAY
YAY I GOT TRY CATCH...YAY
YAY I GOT TRY CATCH...YAY

DO YOU USE TRY CATCH YAY?

No, no! He should have put

On Error Resume Next

at the top of the function to save some typing. It would have the same effect.
Worst error control statement. Ever.

oh, that's just in case they change the TextBox object so that the Text property can return Nothing... who knows what happens in some years ;))

...besides if the Trim function is built it, then, why assign the value? It's already a value.

that's not how it works, trim returns a new string but doesn't change the string that called it.

Wow... I... um... I'm speechless.

But, to stray a bit from the topic, is SpecialEd from "Crank Yankers"? If so, that's exactly the kind of guy I imagine writing this code. :-D !!

I was made to write code like this.

On Error Resume Next does the same thing :). However, there's actually no perf penalty for having the try/catch, except for larger code size.

Step 1: Get exceptions in the language
Step 2: ???
Step 3: All errors handled

The dude got stuck at step 2 obviously...

Heh. If a simple assignment like that fails for one textbox, what on earth makes him think that the next one will work?

If one of those fails, you've got a serious problem that you don't really want to ignore...

On Error Resume Next is a performance dog though (in VB7+ it uses a hidden variable to figure out where to bounce the resume to that's updated after each statement.

Still! At least any fundamental error in Winforms won't stop the vitally important space trimming!

Serenity now!!!

This site is hilarious. How can people write code like this?

More comments at:

http://blog.magenic.com/seans/archive/2004/08/05.aspx

Don't you guys see its obvious? Just in case the Text properties return null, you will get an Exception.

Who would take a chance?

We should develop a plugin for VS.NET to add Try/Catch to every single line.

So we can earn our first million$ !

AS bad as this is, I prefer txtFirstName.Text = Trim(txtFirstName.Text) instead of this version.  But who cares?  The overriding problem is more critical...

:

We should develop a plugin for VS.NET to add Try/Catch to every single line.

So we can earn our first million$ !

One macro project to Safeinate (pat pend) your current selection!

[code language="c#"]

Imports EnvDTE
Imports System.Diagnostics
Public Module MarksUberLeetCodeTools
Sub MakeTheCodeExtraSafe()
DTE.ExecuteCommand("Edit.Replace")
DTE.Find.FindWhat = "^{[^$]*}$"
DTE.Find.ReplaceWith = "Try : \1 : Catch : End Try"
DTE.Find.Target = vsFindTarget.vsFindTargetCurrentDocumentSelection
DTE.Find.MatchCase = False
DTE.Find.MatchWholeWord = False
DTE.Find.MatchInHiddenText = True
DTE.Find.PatternSyntax = vsFindPatternSyntax.vsFindPatternSyntaxRegExpr
DTE.Find.ResultsLocation = vsFindResultsLocation.vsFindResultsNone
DTE.Find.Action = vsFindAction.vsFindActionReplaceAll
DTE.Find.Execute()
DTE.Windows.Item(Constants.vsWindowKindFindReplace).Close()
End Sub
End Module
[/code]

Actually, there is another exception that could be thrown:

InvalidOperationException  (in .NET 2.0, when the Text property is accessed from the wrong thread).



Accessing WinForms controls from the wrong thread can cause all sorts
of problems, but this failsafe software won't have the possibility of
deadlocks anymore when it is recompiled for .NET 2.0, it will just
continue without trimming the text.

Ooooh my. This response is a wtf in itself.

If nulls can occur, they should be tested for. Heck, why not write a function (C#:)

string Trim(string couldBeNull)
{
return null==couldBeNull?null:couldBeNull.Trim();
}

If they 'cannot' happen (should not?) then, why catch the error at this level? Catch it at record level. (Say: the input data contained illegal data).

Just my two pence.

welcome to our site
runescape accounts,
runescape gold,and
runescape power leveling.