• Tim Cartwright (unregistered)

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

  • Jake Vinson (unregistered)

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

  • dood (unregistered)

    man that is nucking futz.

  • Larry Osterman (unregistered)

    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.

  • Michael Russell (unregistered)

    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.

  • cablito (unregistered)

    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.

  • Craig (unregistered)

    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

  • SpecialED (unregistered)

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

    DO YOU USE TRY CATCH YAY?

  • boB (unregistered)

    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.

  • asdfs (unregistered)

    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 ;))

  • G (unregistered)

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

  • Jason Hasner (unregistered)

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

  • Juan Gabriel (unregistered)

    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 !!

  • sigh (unregistered)

    I was made to write code like this.

  • Michael Giagnocavo (unregistered)

    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.

  • Anon (unregistered)

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

    The dude got stuck at step 2 obviously...

  • Ray S (unregistered)

    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...

  • Paul Hill (unregistered)

    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!

  • Sean Schade (unregistered)

    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

  • Abu Haider (unregistered)

    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?

  • setthesun (unregistered)

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

    So we can earn our first million$ !

  • (cs)

    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...

  • (cs) in reply to setthesun

    :
    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#"]
    <FONT size=2><FONT color=#0000ff size=2>

    Imports</FONT><FONT size=2> EnvDTE

    </FONT><FONT color=#0000ff size=2>

    Imports</FONT><FONT size=2> System.Diagnostics</FONT>

    <FONT size=2><FONT color=#0000ff size=2>

    Public</FONT><FONT size=2> </FONT><FONT color=#0000ff size=2>Module</FONT><FONT size=2> MarksUberLeetCodeTools

    </FONT></FONT>

    </FONT><FONT color=#0000ff size=2>Sub</FONT><FONT size=2> MakeTheCodeExtraSafe()

    DTE.ExecuteCommand("Edit.Replace")

    DTE.Find.FindWhat = "^{[^$]*}$"

    DTE.Find.ReplaceWith = "Try : \1 : Catch : End Try"

    DTE.Find.Target = vsFindTarget.vsFindTargetCurrentDocumentSelection

    DTE.Find.MatchCase = </FONT><FONT color=#0000ff size=2>False

    </FONT><FONT size=2>

    DTE.Find.MatchWholeWord = </FONT><FONT color=#0000ff size=2>False

    </FONT><FONT size=2>

    DTE.Find.MatchInHiddenText = </FONT><FONT color=#0000ff size=2>True

    </FONT><FONT size=2>

    DTE.Find.PatternSyntax = vsFindPatternSyntax.vsFindPatternSyntaxRegExpr

    DTE.Find.ResultsLocation = vsFindResultsLocation.vsFindResultsNone

    DTE.Find.Action = vsFindAction.vsFindActionReplaceAll

    DTE.Find.Execute()

    DTE.Windows.Item(Constants.vsWindowKindFindReplace).Close()

    </FONT><FONT color=#0000ff size=2>End<FONT color=#000000 size=2> </FONT><FONT color=#0000ff size=2>Sub</FONT></FONT>

    <FONT size=2><FONT color=#0000ff>End</FONT> <FONT color=#0000ff>Module</FONT><FONT color=#0000ff>

    </FONT></FONT>[/code]
  • Anonymous (unregistered)

    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.

  • Seth (unregistered) in reply to Larry Osterman

    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.

  • (nodebb)
    Comment held for moderation.

Leave a comment on “Writing Bugfree software”

Log In or post as a guest

Replying to comment #22970:

« Return to Article