VB's Error Handling


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 6 123 ... LastLast
Results 1 to 15 of 78

Thread: VB's Error Handling

  1. #1
    John Reynolds Guest

    VB's Error Handling


    This is in response to sample code contained in the latest Guest Opinion by
    Jim Pragit. This code:

    Sub SEH()
    Try
    Open "TESTFILE" for Output as #1
    Write #1, CustomerInformation
    Catch
    Kill "TESTFILE"
    Finally
    Close #1
    End Try
    End Sub

    ...would be an abject failure if file "TESTFILE" didn't exist. The Finally
    block would raise an error. The right way to do this would be:

    Sub SEH()
    Try
    Open "TESTFILE" for Output as #1

    Try
    Write #1, CustomerInformation
    Catch
    Kill "TESTFILE"
    Finally
    Close #1
    End Try
    Catch
    'Tell user
    End Try
    End Sub

    I noticed the same failing in Microsoft's documentation, and seeing it in
    print again, I just had to say something. One could say, "But this isn't
    even real code! VB doesn't have this capability yet!" True, but people who
    have written this type of code before wouldn't make this mistake because
    it's undoubtedly hurt them in the past. It seems obvious to me from reading
    the Microsoft documentation Mr. Pragit got this sample from, that the person
    who wrote that documentation has never used a language with the new features
    being added, as this was not the only glaring error in Microsoft's documentation.

    Just my two cents.

    John Reynolds

  2. #2
    Paul Marshall Guest

    Re: VB's Error Handling

    On 11 Apr 2000 06:40:01 -0700, "John Reynolds" <fastluck@email.com> wrote:

    Hi,

    I wouldn't know a Try...Catch from a foul ball. Could someone please
    explain the difference between this:

    »Sub SEH()
    » Try
    » Open "TESTFILE" for Output as #1
    » Write #1, CustomerInformation
    » Catch
    » Kill "TESTFILE"
    » Finally
    » Close #1
    » End Try
    »End Sub

    and this:

    Sub SEH()
    On Error GoTo Catch
    Open "TESTFILE" For Output As #1
    Write #1, CustomerInformation
    GoTo Finally
    Catch:
    Kill "TESTFILE"
    Finally:
    On Error GoTo 0
    Close #1
    End Sub







    »
    »..would be an abject failure if file "TESTFILE" didn't exist. The Finally
    »block would raise an error. The right way to do this would be:
    »
    »Sub SEH()
    » Try
    » Open "TESTFILE" for Output as #1
    »
    » Try
    » Write #1, CustomerInformation
    » Catch
    » Kill "TESTFILE"
    » Finally
    » Close #1
    » End Try
    » Catch
    » 'Tell user
    » End Try
    »End Sub
    »
    »I noticed the same failing in Microsoft's documentation, and seeing it in
    »print again, I just had to say something. One could say, "But this isn't
    »even real code! VB doesn't have this capability yet!" True, but people who
    »have written this type of code before wouldn't make this mistake because
    »it's undoubtedly hurt them in the past. It seems obvious to me from reading
    »the Microsoft documentation Mr. Pragit got this sample from, that the person
    »who wrote that documentation has never used a language with the new features
    »being added, as this was not the only glaring error in Microsoft's documentation.
    »
    »Just my two cents.
    »
    »John Reynolds


  3. #3
    Michael \(michka\) Kaplan Guest

    Re: VB's Error Handling

    The difference is not in functionality so much as what is happening with an
    exception handler compared with traditional VBA error handling.

    --
    MichKa
    (insensitive fruitarian)

    random junk of dubious value, a multilingual website, the
    54-language TSI Form/Report to Data Access Page Wizard,
    and lots of replication "stuff" at the (no scripts required!)
    http://www.trigeminal.com/


    "Paul Marshall" <pmarshal@vulcraft-al.com> wrote in message
    news:un37fsklmercf7vjqodri6imnsgff4dbgs@4ax.com...
    > On 11 Apr 2000 06:40:01 -0700, "John Reynolds" <fastluck@email.com> wrote:
    >
    > Hi,
    >
    > I wouldn't know a Try...Catch from a foul ball. Could someone please
    > explain the difference between this:
    >
    > »Sub SEH()
    > » Try
    > » Open "TESTFILE" for Output as #1
    > » Write #1, CustomerInformation
    > » Catch
    > » Kill "TESTFILE"
    > » Finally
    > » Close #1
    > » End Try
    > »End Sub
    >
    > and this:
    >
    > Sub SEH()
    > On Error GoTo Catch
    > Open "TESTFILE" For Output As #1
    > Write #1, CustomerInformation
    > GoTo Finally
    > Catch:
    > Kill "TESTFILE"
    > Finally:
    > On Error GoTo 0
    > Close #1
    > End Sub
    >
    >
    >
    >
    >
    >
    >
    > »
    > »..would be an abject failure if file "TESTFILE" didn't exist. The

    Finally
    > »block would raise an error. The right way to do this would be:
    > »
    > »Sub SEH()
    > » Try
    > » Open "TESTFILE" for Output as #1
    > »
    > » Try
    > » Write #1, CustomerInformation
    > » Catch
    > » Kill "TESTFILE"
    > » Finally
    > » Close #1
    > » End Try
    > » Catch
    > » 'Tell user
    > » End Try
    > »End Sub
    > »
    > »I noticed the same failing in Microsoft's documentation, and seeing it in
    > »print again, I just had to say something. One could say, "But this isn't
    > »even real code! VB doesn't have this capability yet!" True, but people

    who
    > »have written this type of code before wouldn't make this mistake because
    > »it's undoubtedly hurt them in the past. It seems obvious to me from

    reading
    > »the Microsoft documentation Mr. Pragit got this sample from, that the

    person
    > »who wrote that documentation has never used a language with the new

    features
    > »being added, as this was not the only glaring error in Microsoft's

    documentation.
    > »
    > »Just my two cents.
    > »
    > »John Reynolds
    >




  4. #4
    Paul Marshall Guest

    Re: VB's Error Handling

    On Tue, 11 Apr 2000 16:24:26 -0700, "Michael \(michka\) Kaplan"
    <former_mvp@spamfree.trigeminal.nospam.com> wrote:

    »The difference is not in functionality so much as what is happening with an
    »exception handler compared with traditional VBA error handling.

    So what _is_ happening with an exception handler as opposed to
    traditional VBA error handling? Is it more than the structure
    it gives to the source code? That, in itself, is nice but...
    "Please, sir, I want some more."


  5. #5
    Michael \(michka\) Kaplan Guest

    Re: VB's Error Handling

    Well, if you look at the assembly that is actually produced for a compiled
    app that uses "conventional" error handling, it is not as efficient as it
    could be.... the reason being that on any line an error might occur and that
    means that the branching to wherever your "on error goto xxxx" points has to
    happen, plus data with labels for anytime a resume or resume next would have
    to happen. This does cause a fair amount of bloating, though, compared to
    code without a bunch of error handlers -- the resume/resume next in
    particular, as it does appear to need to label each line so it can return to
    it if needed -- yuck!

    In C it would be like wrapping every line in an OnErrorGoto procedure that
    would do the same thing, plus a label for each line, as well.... it adds a
    fair amount of overhead.

    The assembly that could *potentially* be created in a model where SEH is
    possible would indeed be a lot more efficient. Now I do not know if this is
    what they WILL do.... but it is certainly possible in the VC compiler that
    VB uses, so the potential for faster code is possible.

    Ok, for user benefit, you can avoid the "goto" stuff and avoid error
    handlers at the way bottom of a proc (often far away from the actual error),
    not to mention the problems with multiple error blocks for different types
    of errors or huge switch statements based on error code, etc.

    Error handling is not the only place that is less efficient in native code
    than in pcode..... gosub is another prime example. Anyone who is used to
    looking at disassembly is invited to look at what gets created for
    gosub/return stuff. Its awful! But its not a bad performer in VB pcode at
    all.... its just a matter of an error handling model that does not work as
    well in native code.

    But I am betting that if they go to all the work to do SEH, that they will
    compile more efficiently. You see, SEH itself has overhead, but then VBA
    uses SEH to handle errors anyway. What you have in VB is what a VC developer
    would consider "badly written exception handling" although we had no choice.

    --
    MichKa
    (insensitive fruitarian)

    random junk of dubious value, a multilingual website, the
    54-language TSI Form/Report to Data Access Page Wizard,
    and lots of replication "stuff" at the (no scripts required!)
    http://www.trigeminal.com/


    "Paul Marshall" <pmarshal@vulcraft-al.com> wrote in message
    news:dbm8fs0buter87ctoq13ht748abnf0dmf1@4ax.com...
    > On Tue, 11 Apr 2000 16:24:26 -0700, "Michael \(michka\) Kaplan"
    > <former_mvp@spamfree.trigeminal.nospam.com> wrote:
    >
    > »The difference is not in functionality so much as what is happening with

    an
    > »exception handler compared with traditional VBA error handling.
    >
    > So what _is_ happening with an exception handler as opposed to
    > traditional VBA error handling? Is it more than the structure
    > it gives to the source code? That, in itself, is nice but...
    > "Please, sir, I want some more."
    >




  6. #6
    Michael \(michka\) Kaplan Guest

    Re: VB's Error Handling

    Actually, let me make a correction (I took another look in the disassembly
    window, one of my good friends <g>). I do not think that the bloat happens
    due to an "OnErrorGoto" type thing because it is not going to labels there,
    at all. But the stuff about resume is true (and slightly worse than I
    thought!).

    The C/C++ code to create such a procedure would be universally condemned as
    inefficient code.

    --
    MichKa
    (insensitive fruitarian)

    random junk of dubious value, a multilingual website, the
    54-language TSI Form/Report to Data Access Page Wizard,
    and lots of replication "stuff" at the (no scripts required!)
    http://www.trigeminal.com/


    "Michael (michka) Kaplan" <former_mvp@spamfree.trigeminal.nospam.com> wrote
    in message news:38f48350@news.devx.com...
    > Well, if you look at the assembly that is actually produced for a compiled
    > app that uses "conventional" error handling, it is not as efficient as it
    > could be.... the reason being that on any line an error might occur and

    that
    > means that the branching to wherever your "on error goto xxxx" points has

    to
    > happen, plus data with labels for anytime a resume or resume next would

    have
    > to happen. This does cause a fair amount of bloating, though, compared to
    > code without a bunch of error handlers -- the resume/resume next in
    > particular, as it does appear to need to label each line so it can return

    to
    > it if needed -- yuck!
    >
    > In C it would be like wrapping every line in an OnErrorGoto procedure that
    > would do the same thing, plus a label for each line, as well.... it adds a
    > fair amount of overhead.
    >
    > The assembly that could *potentially* be created in a model where SEH is
    > possible would indeed be a lot more efficient. Now I do not know if this

    is
    > what they WILL do.... but it is certainly possible in the VC compiler that
    > VB uses, so the potential for faster code is possible.
    >
    > Ok, for user benefit, you can avoid the "goto" stuff and avoid error
    > handlers at the way bottom of a proc (often far away from the actual

    error),
    > not to mention the problems with multiple error blocks for different types
    > of errors or huge switch statements based on error code, etc.
    >
    > Error handling is not the only place that is less efficient in native code
    > than in pcode..... gosub is another prime example. Anyone who is used to
    > looking at disassembly is invited to look at what gets created for
    > gosub/return stuff. Its awful! But its not a bad performer in VB pcode at
    > all.... its just a matter of an error handling model that does not work as
    > well in native code.
    >
    > But I am betting that if they go to all the work to do SEH, that they will
    > compile more efficiently. You see, SEH itself has overhead, but then VBA
    > uses SEH to handle errors anyway. What you have in VB is what a VC

    developer
    > would consider "badly written exception handling" although we had no

    choice.
    >
    > --
    > MichKa
    > (insensitive fruitarian)
    >
    > random junk of dubious value, a multilingual website, the
    > 54-language TSI Form/Report to Data Access Page Wizard,
    > and lots of replication "stuff" at the (no scripts required!)
    > http://www.trigeminal.com/
    >
    >
    > "Paul Marshall" <pmarshal@vulcraft-al.com> wrote in message
    > news:dbm8fs0buter87ctoq13ht748abnf0dmf1@4ax.com...
    > > On Tue, 11 Apr 2000 16:24:26 -0700, "Michael \(michka\) Kaplan"
    > > <former_mvp@spamfree.trigeminal.nospam.com> wrote:
    > >
    > > »The difference is not in functionality so much as what is happening

    with
    > an
    > > »exception handler compared with traditional VBA error handling.
    > >
    > > So what _is_ happening with an exception handler as opposed to
    > > traditional VBA error handling? Is it more than the structure
    > > it gives to the source code? That, in itself, is nice but...
    > > "Please, sir, I want some more."
    > >

    >
    >




  7. #7
    Paul Marshall Guest

    Re: VB's Error Handling

    On Wed, 12 Apr 2000 07:26:37 -0700, "Michael \(michka\) Kaplan"
    <former_mvp@spamfree.trigeminal.nospam.com> wrote:

    »But the stuff about resume is true (and slightly worse than I
    »thought!).

    That sounds like what I was looking for. Let's see if
    I understand: the improvement in Try...Catch...Finally
    ....End Try over On Error... is in source structure and
    in that the compiler won't have to deal with possible
    Resume (Next) statements, which it apparently handles
    poorly. Am I close?


  8. #8
    Michael \(michka\) Kaplan Guest

    Re: VB's Error Handling

    Yes, very close, in fact.

    --
    MichKa
    (insensitive fruitarian)

    random junk of dubious value, a multilingual website, the
    54-language TSI Form/Report to Data Access Page Wizard,
    and lots of replication "stuff" at the (no scripts required!)
    http://www.trigeminal.com/


    "Paul Marshall" <pmarshal@vulcraft-al.com> wrote in message
    newsc59fs4fufcroti5ig99rrtekfsfgcq5sm@4ax.com...
    > On Wed, 12 Apr 2000 07:26:37 -0700, "Michael \(michka\) Kaplan"
    > <former_mvp@spamfree.trigeminal.nospam.com> wrote:
    >
    > »But the stuff about resume is true (and slightly worse than I
    > »thought!).
    >
    > That sounds like what I was looking for. Let's see if
    > I understand: the improvement in Try...Catch...Finally
    > ...End Try over On Error... is in source structure and
    > in that the compiler won't have to deal with possible
    > Resume (Next) statements, which it apparently handles
    > poorly. Am I close?
    >




  9. #9
    Paul Marshall Guest

    Re: VB's Error Handling

    On Wed, 12 Apr 2000 11:53:45 -0700, "Michael \(michka\) Kaplan"
    <former_mvp@spamfree.trigeminal.nospam.com> wrote:

    Thanks for your help.


  10. #10
    Thomas Guest

    Re: VB's Error Handling

    Are you saying that the "On Error Resume Next" functionality is on the
    way out?

    With Try/Catch/Finally constructs, how can you ignore errors in-line
    like you can with "On Error Resume Next" ?

    Now I agree that:
    On Error Goto X
    ....
    X:
    ...
    Resume Next

    is totally crap code. But I do like the ability to ignore errors that
    "On Error Resume Next" allows. For example, if you need to delete a
    file (if it exists) before you open it again for writing, it is very
    easy to do

    On Error Resume Next
    Kill FileName
    on Error Goto 0

    Open FileName....


  11. #11
    Colin McGuigan Guest

    Re: VB's Error Handling

    Thomas wrote in message <38f73361.3844298@news.devx.com>...
    <snip>
    >But I do like the ability to ignore errors that
    >"On Error Resume Next" allows. For example, if you need to delete a
    >file (if it exists) before you open it again for writing, it is very
    >easy to do
    >
    >On Error Resume Next
    >Kill FileName
    >on Error Goto 0
    >
    >Open FileName....
    >


    Is OERN on the way out? Nah. VB bends over backwards to maintain backwards
    compatibility.

    However, in SEH-land, the code above would be:

    Try
    Kill FileName
    Catch
    'Do Nothing
    End Try

    --
    Colin McGuigan




  12. #12
    Vlad Ivanov Guest

    Re: VB's Error Handling


    I think that this might work too (and looks nicer)

    Try
    Kill FileName
    End Try

    Sort of like not having an Else in an If/End If.

    Not that i know it will will/won't work. Just feels like a more stylistically
    correct replacement for:

    On error resume next
    Kill FileName
    On error goto 0


    I would go even further. You know how you can have an If statement without
    End If?

    Kinda like:

    If fDelete then Kill FileName

    The paramount of simplicity in a situation like this would be :

    Try Kill FileName

    Elegant

    >However, in SEH-land, the code above would be:
    >
    >Try
    > Kill FileName
    >Catch
    > 'Do Nothing
    >End Try
    >
    >--
    >Colin McGuigan
    >
    >
    >



  13. #13
    Michael \(michka\) Kaplan Guest

    Re: VB's Error Handling

    I am not saying anything since Microsoft has not released any info.

    I am merely taking what is known about VB6, what little is known about VB7,
    and assuming that some of the VB6 problems in error handling would be
    addressd by the new VB7 stuff.

    They might not do all that, who knows?

    --
    MichKa
    (insensitive fruitarian)

    random junk of dubious value, a multilingual website, the
    54-language TSI Form/Report to Data Access Page Wizard,
    and lots of replication "stuff" at the (no scripts required!)
    http://www.trigeminal.com/


    "Thomas" <thomas3617@spamcop.net> wrote in message
    news:38f73361.3844298@news.devx.com...
    > Are you saying that the "On Error Resume Next" functionality is on the
    > way out?
    >
    > With Try/Catch/Finally constructs, how can you ignore errors in-line
    > like you can with "On Error Resume Next" ?
    >
    > Now I agree that:
    > On Error Goto X
    > ...
    > X:
    > ...
    > Resume Next
    >
    > is totally crap code. But I do like the ability to ignore errors that
    > "On Error Resume Next" allows. For example, if you need to delete a
    > file (if it exists) before you open it again for writing, it is very
    > easy to do
    >
    > On Error Resume Next
    > Kill FileName
    > on Error Goto 0
    >
    > Open FileName....
    >




  14. #14
    Michael \(michka\) Kaplan Guest

    Re: VB's Error Handling

    "Colin McGuigan" <colin@chicor.com> wrote in message
    news:38f73949$1@news.devx.com...
    > Is OERN on the way out? Nah. VB bends over backwards to maintain backwards
    > compatibility.


    Never say never..... just when you think something is supported, new
    versions can change the rules. It has happened in every other part of MS, so
    believing they would never do it here is not necessarily the best way to
    think.

    MS is embracing a "Field of Dreams" marketing theory (If they build it, we
    will come). :-)

    --
    MichKa
    (insensitive fruitarian)

    random junk of dubious value, a multilingual website, the
    54-language TSI Form/Report to Data Access Page Wizard,
    and lots of replication "stuff" at the (no scripts required!)
    http://www.trigeminal.com/



  15. #15
    Colin McGuigan Guest

    Re: VB's Error Handling

    Michael (michka) Kaplan wrote in message <38f74369@news.devx.com>...
    >"Colin McGuigan" <colin@chicor.com> wrote in message
    >news:38f73949$1@news.devx.com...
    >> Is OERN on the way out? Nah. VB bends over backwards to maintain

    backwards
    >> compatibility.

    >
    >Never say never..... just when you think something is supported, new
    >versions can change the rules. It has happened in every other part of MS,

    so
    >believing they would never do it here is not necessarily the best way to
    >think.
    >
    >MS is embracing a "Field of Dreams" marketing theory (If they build it, we
    >will come). :-)
    >
    >--
    >MichKa
    >(insensitive fruitarian)



    In some parts, I agree with this; however, I can't think of a single
    language syntax that has changed how it worked (syntactically) from VB 1 on
    up. ****, we still have Line and Circle. They (Microsoft) may have broken
    some code by changing how things work behind the scenes (such as the
    Initialize and InitProperties of controls...), but for the syntax itself, I
    honestly can't think of any native VB language thing you could do in a
    previous version that you can't do now, and I think that'll extend into VB7.


    --
    Colin McGuigan




Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center