VB6 very poor



  •  

    I'm currently fixing a vb6 application and I came across this little gem.

    Please tell me, is it the programmer or the language?

    The form in question has heaps of controls that don't have a datafield property or a datasource property.

    I went wtf when I saw how much time this method spent in the errorhandler.

    Public Sub ReBindEcho()
    On Error GoTo BindError

    'SNIP

        ' Bind the appropriate controls to the database
        For Each ctrlTemp In Me.Controls
        
                If ctrlTemp.DataField > "" Then
                Set ctrlTemp.DataSource = Nothing
                Set ctrlTemp.DataSource = MainDE
                If TypeOf ctrlTemp Is DataCombo Then Set ctrlTemp.RowSource = MainDE
                End If
            
        Next ctrlTemp   

    'SNIP


    BindError:
        If Err.Number <> 0 Then
            Resume Next
        End If
    End Sub



  • It's the quote-progammer-unquote

    This is a real gem of awful VB code.  I think it deserves front page status, but VB is pretty well-mined territory.

    The "BindError:" error handler thing is especially delicious.



  • Wow, that's one bit of code. This is one of those unusual situations
    where an "ON ERROR RESUME NEXT" or a GOTO would have improved the code
    100x.



    Since he's discarding every single error, why not just do a resume next on errors?



    Since you've got a (non-functional) error handler, why the F would you
    not have either another GOTO to a label past the error handler or
    better yet an "Exit Sub" before the error handler rather than blindly
    walking into an error handler when you have no error?



    Oh, and what does "greater than an empty string" mean? What would less
    than an empty string mean? Who would even write such a thing, even if
    it works and compiles?



    As Judge Judy and exectioner, I have to declare VB6 the victim in this
    case, and the original code-monkey (I can't bring myself to call him a
    developer, coder, programmer, etc) an evil spawn of the devil. £10m to
    the defendant.



  • I have to disagree.  Although the coder is certainly an idiot for doing things like that, VB is notorious for encouraging such braindead behaviour.  Just think:  a programming language that wants to be all things to all people by offering convenient access to OS API, COM and other underlying frameworks, but whose only exception handling primitives are an unconditional ignore or a generic goto.

    Those who "learn" to program on such platform are usually damned to do such things.

        dZ.



  • ON ERROE RESUME NEXT does appear in other places. It's interesting because it makes it so much harder to debug.

    I couldn't get over the fact that the test for err.number > 0 was there to guide the program out of the bottom end of the method.

    In other places, text is assigned to textboxes that don't even exist. I'm not kidding, the compiler allows the code to be compiled with phantom references (I found it difficult to get over that one as well!).

    As for the test for "greater then empty string". All I can say is that I probably wouldn't have tackled it like that. Having said that, I blame the compiler (language) for allowing it.

    Obviously we are looking at a challenged code-monkey here!

    I myself give 1 vote code-monkey, 1 vote vb6.







  • @DZ-Jay said:

    I have to disagree.  Although the coder is
    certainly an idiot for doing things like that, VB is notorious for
    encouraging such braindead behaviour.  Just think:  a
    programming language that wants to be all things to all people by
    offering convenient access to OS API, COM and other underlying
    frameworks, but whose only exception handling primitives are an
    unconditional ignore or a generic goto.

    Those who "learn" to program on such platform are usually damned to do such things.




    Hey, I learned on VB(A)6 (after moving from BASIC+machine code on a
    C64), and am now doing quite well on C#/VB living in a fully
    exceptioned world, thanks. ;-)



    Admittedly error handling in VB6 is lame, but not quite as bad as you
    suggest. Ignoring the error with on error resume next is just coder
    laziness. You're fully able to inspect the error number afterwards and
    act accordingly. that unconditional goto you mention is actually a
    gosub which, while ugly (ok, VERY ugly), can do the job almost as well
    if you do it properly.



    Still, a bad coder is a bad coder no matter the language tools. While
    you don't see on error resume next in other languages, "try; //do
    stuff; catch ex as exception; //oh crap, ignore error; end try" is
    common enough to be scary.



    Still, although I'm glad at VB6 being in the past, it wasn't quite as bad any many think if managed properly.



  • @RayS said:

    Oh, and what does "greater than an empty string" mean? What would less than an empty string mean? Who would even write such a thing, even if it works and compiles?

    I haven't done VB in ages, but several other languages allow > and friends with strings - presumably it means "comes after the empty string in dictionary order", in other words, "is not the empty string".  Perhaps it's not the absolutely most clear way of writing it, but not worthy of mention IMHO.



  • Do you have a better idea?

    The programmer is obviously aware of how to check the type of an object. And since VB doesn't have good reflection support, I don't see any good way to handle this situation.

    That said, I agree that the Resume Next is misplaced.

     



  • @RayS said:

    @DZ-Jay said:
    I have to disagree.  Although the coder is certainly an idiot for doing things like that, VB is notorious for encouraging such braindead behaviour.  Just think:  a programming language that wants to be all things to all people by offering convenient access to OS API, COM and other underlying frameworks, but whose only exception handling primitives are an unconditional ignore or a generic goto.

    Those who "learn" to program on such platform are usually damned to do such things.


    Hey, I learned on VB(A)6 (after moving from BASIC+machine code on a C64), and am now doing quite well on C#/VB living in a fully exceptioned world, thanks. ;-)

    Admittedly error handling in VB6 is lame, but not quite as bad as you suggest. Ignoring the error with on error resume next is just coder laziness. You're fully able to inspect the error number afterwards and act accordingly. that unconditional goto you mention is actually a gosub which, while ugly (ok, VERY ugly), can do the job almost as well if you do it properly.

    Still, a bad coder is a bad coder no matter the language tools. While you don't see on error resume next in other languages, "try; //do stuff; catch ex as exception; //oh crap, ignore error; end try" is common enough to be scary.

    Still, although I'm glad at VB6 being in the past, it wasn't quite as bad any many think if managed properly.

    <FONT face=Tahoma>Me too, I started off programming in VB although I was first taught with C, Java and COBOL (COBOL was fun though...) programming languages, during my early years in a university.

    After about 2 years, VB was introduced and I really liked it because it's very easy to learn. Though I really regret that I didn't focus on either C or Java, but I'm just starting to learn the programming concepts back then and VB would be a good "practice" point (no need to worry about confusing braces and keywords that time). The good thing though is that I never really grasped the thought of using the on error resume next in those years ;)

    And it made my transition to VB.NET really smooth after graduation. And today, after just a year off college, I made it back to a language similar to C and Java without difficulties...And everything's good for me now...

    The only significant difference I noticed from VB and C#, as far as I can remember, is the syntax, error handling, and the OO concept.

    So yeah, it really is easy for anyone to learn VB, and that means ANYONE...but I think that wouldn't be VB's fault...anyone can drive a car, but only those who really knew how to drive can drive properly...



    </FONT>


  • ♿ (Parody)

    @musigenesis said:

    I think it deserves front page status, but VB is pretty well-mined territory.

    The code is bad, but is definitely more suited for this side bar. Unless I'm missing something, this seems to be effectively the following (anti-) pattern ...

    foreach (thing in things)
    {
     try { thing.somethingThatMayFail(); }
     catch { //ignore error }
    }

    There may be some VB6 specific things that I'm missing, but if that's the case, a lot of readers would also miss out on that ...



  • It's the programmer, get real! Ignoring errors!  And don't tell me this is limited to VB, all you need to do in Java is an empty catch {}.  In C, it's even easier, just ignore the returned code.
    You'd think he would have used the TypeOf to limit what gets a datasource, but no, he's a clueless one.

    Using > on a string to mean <> (not equal) is a pretty strange thing on it's own, but probably works...



  • You could blame the language and compiler for being too flexible. But if VB6 allows us to do these things, why don't I write my code that way? Simple answer, I'm not a moron.

    Well, I might be, but I try to keep my code a lot cleaner than this. I don't even believe in doing If String <> "", I feel compelled to test If Len(String) > 0.

    I'm still curious about why he sets the DataSource to Nothing, then to MainDE. Hey that data source, just clear it out, we don't need it so you can relax HAHAH GOTCHA!!! Woohoo you shoulda seen the look on your face! Now what kind of control are you? SPEAK UP!



  • I have written a lot of VBA in Excel, VB6, and VB.NET 2002 and 2005 code, and I have NEVER used On Error Resume Next.  It just boggles my mind to think that any piece of code would benefit from that statement.

    I also didn't use Option Explicit in VBA; I liked being able to create variables without having to declare them... and misspelling a variable name wasn't the kind of error I was prone to make.  But that was just me. 

    Now, in VB.NET 2005, I declare everything.

     



  • Deliberately not declaring variables? Ouch. Forget GOTOs and ON ERRORs,
    for me the biggest WTF in VBClassic wasallowing exactly that sort of
    thing. OPTION EXPLICIT isn't just for making a statement of your
    preference in porn.



  • @DWalker59 said:

    I have written a lot of VBA in Excel, VB6, and VB.NET 2002 and 2005 code, and I have NEVER used On Error Resume Next.  It just boggles my mind to think that any piece of code would benefit from that statement.

    I also didn't use Option Explicit in VBA; I liked being able to create variables without having to declare them... and misspelling a variable name wasn't the kind of error I was prone to make.  But that was just me. 

    Now, in VB.NET 2005, I declare everything.

     

    If you don't use On Error Resume Next in VB6/VBA, then you are either ignoring errors or using GOTO's to jump around your code to handle errors.  Both are bad programming techniques. (Then again, so is not using Option Explicit )

    If the error handling features of VBA/VB6 are all that is available to you, there is nothing wrong with:

    On Error Resume Next
    MkDir "C:\Somefolder"
    If Err.Number <> 0 Then .... handle error
    On Error Goto 0

    As always, good programming is not dependant on *what* language you are using; it is dependant on *how* you are using that language.


  • @DZ-Jay said:

    I have to disagree.  Although the coder is certainly an idiot for doing things like that, VB is notorious for encouraging such braindead behaviour.  Just think:  a programming language that wants to be all things to all people by offering convenient access to OS API, COM and other underlying frameworks, [b]but whose only exception handling primitives are an unconditional ignore or a generic goto[/b].

    Those who "learn" to program on such platform are usually damned to do such things.

        dZ.


    Unfortunately, the highlighted part in the quote above is completely wrong (see my previous post).  Those who "don't learn" to program on such a platform probably shouldn't be critizing it.



  • @Jeff S said:

    @DZ-Jay said:
    I have to disagree.  Although the coder is certainly an idiot for doing things like that, VB is notorious for encouraging such braindead behaviour.  Just think:  a programming language that wants to be all things to all people by offering convenient access to OS API, COM and other underlying frameworks, [b]but whose only exception handling primitives are an unconditional ignore or a generic goto[/b].

    Those who "learn" to program on such platform are usually damned to do such things.

        dZ.


    Unfortunately, the highlighted part in the quote above is completely wrong (see my previous post).  Those who "don't learn" to program on such a platform probably shouldn't be critizing it.


    I'd have to disagree. The unconditional ignore is On Error Resume Next. The generic goto is On Error Goto SomeErrorHandler. The statement he made is no where near completely wrong. It could be partially wrong if you want to argue what generic means. You could try to argue that the person making that statement meant that there could only be one Goto in the whole program, but that's just a stupid assumption. Also, technically there is On Error Goto 0 which disables error handling, however now we are just nit-picking. I just don't see how that statement is completely wrong.



  • With on error resume next enabled, ErrNo is populated with the error
    number returned. It is the programmer that "unconditionally ignores"
    this, not the language. VB is saying "Look look I found an error for
    you, error number 45!!". It's just not being reported in a try/catch
    style block.

    Calling it an unconditional ignore is therefore very misleading. All ignoring is done so by the programmer not the language..



    Despite the "on error goto" syntax, it really isn't a goto,
    since you can very easily resume/return from where you left off, making
    it act more like a gosub. Despite the syntax, it's not really a goto,
    which implies a one-way trip (although it still can be, should you
    wish).



    The originally referenced post isn't "completely wrong", just misleading and/or ill-informed.



Log in to reply