Hello All,

Although, I have read all the advantages of using Try Catch Block
instead of "On error goto", I am still confused what is alternative for
classic "Resume" statement. "Resume" was one of the crucial line in
debugging which let VB programmers go to exact line where error was
thrown.

I still use on error goto instead of try catch since, I want "Resume"
for debugging. Is there any alternative like Resume in VB.net for Try
catch block?

Best Regards,
Pravin

I really don't understand what you are trying to say. You can debug to the
line of error in .NET with Try Catch.. Whenever there is a error, in a Try
block, its thrown into the catch statement in the same try or in any upper
level catch. If you do something like below...

Try

        ' statements


Catch ( Exception ex)

    ' ex.Tostring() <- will give you the line number where the error was..
This is assuming you complied in
                                debug mode
End try

Hope I have explained what you are looking for..

VJ

Show quoteHide quote

It's not just question of line number! It's the complete stack and
values of all parameters.   By setting your next line to resume after
error you could jump to line which gave error without leaving
execuation. In VB 6, we used fix problem also.

If you are VB programmer and never used resume you have never seen the
beauty of VB debugging.

see following classic VB code
sub test()
On error got hell

  'yada yada yada
  'yada yada yada

exit_hander:
  exit sub
hell:
   msgobx error
   resume exit_handler
   resume
end sub

Now after you get an error, instead of clicking ok, hit Ctrl+Break (in
VB 6.0 though). Then you will go in debug mode. Now, set your next
statement as "resume". It will take your execuation on line which gave
error with whole state preserved. Basically, you reach a line just
before error was thrown.



After knowing the line number you must set breakpoint

Neo wrote:
Show quoteHide quoteIf you want to be able to enter debug mode at the point at which the error
occurred, you can open the Exceptions window (Debug / Exceptions) and check
the "Throw" box for the Common Language Runtime Exceptions row. This will
break as soon as the exception occurs, meaning you don't need to rely on the
hidden "Resume" statement to get back to where you were.

As for the structure of your code, I think you need to re-adjust the way you
think about error handling. If that's a typical scenario in which you want
to use Resume along with a label, either of these would produce the same
results:

\\\
    Sub Test
        Try
            'Yada yada yada
            'Yada yada yada

        Catch ex As Exception
            MsgBox(ex.Message)

        Finally
            'Exit handler code goes here
        End Try
    End Sub
///

....or...

\\\
    Sub Test
        Try
            'Yada yada yada
            'Yada yada yada

        Catch ex As Exception
            MsgBox(ex.Message)

        End Try

        'Exit handler code goes here
    End Sub
///

Not sure that's really what you're looking for but perhaps you'll find some
of it useful.

Thanks.. you have precisely answered my question. Thanks a lot. I
really appreciate this. I hope All these bulky book about VB 2005 could
mentioned these alternatives in bold letters.

This is not just alternative for "resume", it is better since, I don't
have to type hidden line of resume.

Thanks!

Ahh.. now I get it.. been a while I did Classic VB, I almost forgot this....
anyways like others said.. only way is try/catch around each statement...
Now also if you use the current Edit/Continue in 2005 it provides a similar
functionality.. but like a 1-1 match with Resume..

VJ
Show quoteHide quote

Resume allowed the code to continue while in an error state.  This allowed
the programmer to attempt to correct the problem and continue on.  I would
propose nested try catch finally statements to get you where you would like
to go.

given:

On Error Resume Next

dim iRet as Long

iRet = objTemp.Blowup

if Err.number <> 0 or iRet <> 0 then
err.clear
correct the state and move on
end if

becomes:

dim iRet as integer

try
    try
        iRet = objTemp.Blowup
    catch SpecificException1
        'Known expected exception #1
    catch SpecificException2
        'Known expected exception #2
    catch ex as exception
        'Unexpected exception and potentially unrecoverable
        throw new applicationexception("An uncorrectable error condition
occured.")
    Finally
        'Use this block to recover what you can
    end try
    'continue on with your logic
catch ex as exception
    'Log exception
    'Notify UI
    'Clean up
end try

Show quoteHide quote

you know; i'm really excited that you just said this; i was trying to
do it earlier and it was choking; but i'll go back and give it another
try
i'm just stoked you said that comment; thanks

trying to rewrite this app in vb6 that is like months and months
overdue; i mean-- rewriting it in .NET basically a buinch of ETL type
stuff

is it going to be easy to consume this VB2005 DLL once i get into SSIS?

Unfortunately there is no direct equivalent for 'Resume' available.  You'll
have to put every single line into a separate 'Try...Catch' block to
archieve similar behavior.

Thanks for reply. But I am not looking for On error resume next (as
reply explain), I am talking about just "Resume" statement. Just stand
alone "Resume" statemet, to be precise.

I see, Try Catch doesn't have that cool thing what "resume" has.
Anyways, I still use On error in VB.net not because, I don't know how
to you use try catch, but because, it doesn't let me do what I used in
classic VB. i.e. Jumping to line where an error occured by setting next
statement in debug mode to "Resume", while preserving param values and
stack.

Not yet in VS 2005 but...

You could also add try/catch as you go along (if you don't have a handler
the exception is raised and you can correct before retrying the line). Once
tested you can add the try/catch block for more exceptional code (or you
could use conditional compilation to have a global handler in release mode
but not in debug mode). Finally the handler catch only the exception you
specified (i.e. a try catch block could catch known possible error but let
you debug other errors).


1144247983.472391.17***@i40g2000cwc.googlegroups.com...
Show quoteHide quote

Neo,

Is there somebody who says that you should not what you think is the best?

That is the pleasure from VBNet it let you do it as it fits you the best.

(Not that I use it before you think that, the Try Catch Finally fits me
exact)

Just my thought,

Cor

I fully agree with you. I am very happy with VB.net.

Especially when I have seen, code getting ugly if you do Office
automation in C#  with by passing missing object for optional
arguments. I don't understand why would anyone write office automation
code in C# when you have VB. Even object browser doesn't work in C# for
Office interops.

With VB.net 2005, I could port my VBA code, Win APIs to VB.net code. I
am not interested in writing platform independent code, I just want to
exploit all features in .Net along with windows native APIs, glueing
with COM. All my clients are on Windows, all my servers are on Windows.
and with VB.net 2005. I can do things just the way I like them. Three
cheers to VB.net 2005!!

Show quote Hide quote The following works in VB.Net

Sub Main()

        On Error GoTo errHandle
        Console.WriteLine("line 1")
        Throw New Exception
        Console.WriteLine("Line 3")
        Console.ReadLine()

errHandle:
        Console.WriteLine("In Handler")
        Resume Next
    End Sub

That being said, I agree with those who argue that if an exception is thrown,
your application is in an invalid state and should not be allowed to just
continue without explicit handling of some sort, even if it is simple logging.
I do not use the above in .Net applications nor do I recommend it.

Jim Wooley
http://devauthority.com/blogs/jwooley

Neo,
In addition to the other comments.

The "best" you could do is to put a Try/Catch around each of the commands
you want retry and have the Catch block retry the Try Block. I find using
Goto in the Catch block the "easiest" way to "Retry", others have put the
entire Try/Catch in a loop...

BTW: I've heard all the arguments about how Goto is evil & should be
avoided, in this case the "Goto Retry" is more like a "Retry" statement. Yes
"goto retry" could be used for evil, however it can also be used for good...

Something like:

            If MessageBox.Show("File does not exit!", _
                    Application.ProductName, _
                    MessageBoxButtons.RetryCancel, _
                    MessageBoxIcon.Question, _
                    MessageBoxDefaultButton.Button2) _
                    = DialogResult.Retry Then
                GoTo Retry
            End If

Caution: With either the Goto Retry or a loop, be certain to allow your
users an Out, so you don't get into an endless loop.



Show quoteHide quote

Excellent idea. Thanks.

Installer Project - Conditions on Custom Action
How to "append" a datatable?
Insert into database
Running program in VB.NET doesn't work?
Query based on a text box value..
Read-only collection...
Content of Datagridview to Excel
One line of code not working : susposed to resize datagrid column..
Embed file
GDI+ Rendering Text and scrolling