|
web
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Resume next in VB.NET ?In VB 6.0 in the error trapping, we can do "resume next" to continue on the
next code. How can we do that in .NET with "Try", "Catch","End Try" ? Thanks "fniles" <fni***@pfmail.com> wrote in Trynews:OAFzz63pGHA.3820@TK2MSFTNGP05.phx.gbl: > In VB 6.0 in the error trapping, we can do "resume next" to continue > on the next code. How can we do that in .NET with "Try", "Catch","End > Try" ? Thanks > > > Catch ex As Exception Response.Write(ex.message) End Try Does that help? There is an equivalent, but it's not very attractive:
Try <statement 1> Catch 'do nothing End Try Try <statement 2> Catch 'do nothing End Try -- Show quoteHide quoteDavid Anton www.tangiblesoftwaresolutions.com Instant C#: VB to C# converter Instant VB: C# to VB converter Instant C++: C#/VB to C++ converter C# Code Metrics: Quick metrics for C# "fniles" wrote: > In VB 6.0 in the error trapping, we can do "resume next" to continue on the > next code. How can we do that in .NET with "Try", "Catch","End Try" ? > Thanks > > > It's still there (unfortunately).
You can say: On Error Resume Next. However, this does not work with try/catch. It's one or the other. My recommendation is to get rid of On Error Resume Next, and always use Try/Catch in the appropriate places. Usually if an unexpected run time error ocurred, you don't want to execute any more statements - so I never really understood why you would want to Resume Next. If an error happens that you were not expecting, you need to handle it, and get out appropriately. Show quoteHide quote "fniles" <fni***@pfmail.com> wrote in message news:OAFzz63pGHA.3820@TK2MSFTNGP05.phx.gbl... > In VB 6.0 in the error trapping, we can do "resume next" to continue on > the next code. How can we do that in .NET with "Try", "Catch","End Try" ? > Thanks > Thank you all for your replies.
In VB 6 at the top of a sub I used to put "on error goto err_routine", and in err_routine I will write the error to a file and do resume next, because the "resume next" is helpful during debuging a program, because I can put a break point on the Resume Next and when I hit F8 it will go to the next code so that I know where the error occurs. In VB.NET where is the best place to put Try/catch, because if I put it only for 1 line of code, it won't catch error on the other lines of code in that same subroutine. So, I ended putting Try/catch at the top of the subroutine, and include all the codes in that subroutine under "Try". When I get an error, even knowing ex.message sometimes it is difficult to know which line of code causes the problem, and I would like to know which line is it that produced the error. With resume next, I will be able to tell during debuging. Is there any way to do this ? Show quoteHide quote "Marina Levit [MVP]" <someone@nospam.com> wrote in message news:OkfqsL4pGHA.4208@TK2MSFTNGP04.phx.gbl... > It's still there (unfortunately). > > You can say: On Error Resume Next. > > However, this does not work with try/catch. It's one or the other. > > My recommendation is to get rid of On Error Resume Next, and always use > Try/Catch in the appropriate places. Usually if an unexpected run time > error ocurred, you don't want to execute any more statements - so I never > really understood why you would want to Resume Next. If an error happens > that you were not expecting, you need to handle it, and get out > appropriately. > > "fniles" <fni***@pfmail.com> wrote in message > news:OAFzz63pGHA.3820@TK2MSFTNGP05.phx.gbl... >> In VB 6.0 in the error trapping, we can do "resume next" to continue on >> the next code. How can we do that in .NET with "Try", "Catch","End Try" ? >> Thanks >> > > You're struggling with one of the major differences between unstructured
error handling (VB6) and structured error handling (VB.NET - all versions). In VB6, each Sub or Function could only have a single error block, which translated into additional, smaller, superflous, subs and functions to nest error handling. In VB.NET, you can have multiple, nested error handlers. Here's how to do it - For each section of code you wish to protect, put the keyword "try" before it. At the end of the protected code, put the keyword "Catch" with an exception type to handle. You can catch different types of exceptions for the same try block. Finally, if there is any clean up code that you need to execute before leaving the "try" block, use the keyword "Finally" and put the code after it. The last line of the try block is "End Try" try ' Protected Code catch fEx as system.FileException ' File errors catch ex as Exception ' All other errors Finally ' clean up code - release file handles, etc. end try At any time, you can nest try...catch...[finally]...end try blocks, even inside a catch or finally handler. An easy way to start converting is to find your On Error Goto statement and replace it with Try. At the error label, replace this with Catch ex as Exception. At the end of the routine, insert an End Try. If you have a resume statement, replace it with "Finally" (before the end try) and move the code from the resume target into the finally block. For example - sub MySub() On error goto myErr ' Protected Statement ResumeHere: ' Clean up code exit sub myErr: ' Error Handler resume ResumeHere end sub becomes sub MySub() Try ' Protected Statement Catch ex as exception ' Error Handler - note: you can use multiple catch statements, one for each type of error you expect to have; If none of your catch statements can handle the error, it is automatically propagated up the call stack to the next level of error handling. Finally ' Clean up code End Try end sub As for "On Error Resume Next", it's still useful, especially if you are configuring an environment for your application and some parts of the environment already exist and you would get an error back when you attempt to configure previously existing parts. Keep these sections of code as short as possible (I never need more than 10 lines under this type of control). All uses of On Error Goto ... should be immediately replaced with try blocks. Mike Ober. Show quoteHide quote "fniles" <fni***@pfmail.com> wrote in message news:%23mJdVj4pGHA.516@TK2MSFTNGP05.phx.gbl... > Thank you all for your replies. > In VB 6 at the top of a sub I used to put "on error goto err_routine", and > in err_routine I will write the error to a file and do resume next, > because the "resume next" is helpful during debuging a program, because I > can put a break point on the Resume Next and when I hit F8 it will go to the > next code so that I know where the error occurs. > > In VB.NET where is the best place to put Try/catch, because if I put it only > for 1 line of code, it won't catch error on the other lines of code in that > same subroutine. > So, I ended putting Try/catch at the top of the subroutine, and include all > the codes in that subroutine under "Try". When I get an error, even knowing > ex.message sometimes it is difficult to know which line of code causes the > problem, and I would like to know which line is it that produced the error. > With resume next, I will be able to tell during debuging. > > Is there any way to do this ? > > "Marina Levit [MVP]" <someone@nospam.com> wrote in message > news:OkfqsL4pGHA.4208@TK2MSFTNGP04.phx.gbl... > > It's still there (unfortunately). > > > > You can say: On Error Resume Next. > > > > However, this does not work with try/catch. It's one or the other. > > > > My recommendation is to get rid of On Error Resume Next, and always use > > Try/Catch in the appropriate places. Usually if an unexpected run time > > error ocurred, you don't want to execute any more statements - so I never > > really understood why you would want to Resume Next. If an error happens > > that you were not expecting, you need to handle it, and get out > > appropriately. > > > > "fniles" <fni***@pfmail.com> wrote in message > > news:OAFzz63pGHA.3820@TK2MSFTNGP05.phx.gbl... > >> In VB 6.0 in the error trapping, we can do "resume next" to continue on > >> the next code. How can we do that in .NET with "Try", "Catch","End Try" ? > >> Thanks > >> > > > > > > Thank you for your reply. It is very helpful.
>> For each section of code you wish to protect, put the keyword "try" I really want to protect all codes in the subroutine, so replacing the "On >> before > it. Error Goto" statement at the top of the sub with the Try is a good idea (otherwise I will have to put "try/catch" everywhere in the subroutine) The problem with this is, when I get an error, I really do not know which section of the code the error comes from, while in VB6, with Resume Next statement in my error label section, I can know which code it comes from. Show quoteHide quote "Michael D. Ober" <ober***@.alum.mit.edu.nospam> wrote in message news:dVCug.9141$PE1.4920@newsread2.news.pas.earthlink.net... > You're struggling with one of the major differences between unstructured > error handling (VB6) and structured error handling (VB.NET - all > versions). > In VB6, each Sub or Function could only have a single error block, which > translated into additional, smaller, superflous, subs and functions to > nest > error handling. In VB.NET, you can have multiple, nested error handlers. > Here's how to do it - > > For each section of code you wish to protect, put the keyword "try" before > it. At the end of the protected code, put the keyword "Catch" with an > exception type to handle. You can catch different types of exceptions for > the same try block. Finally, if there is any clean up code that you need > to > execute before leaving the "try" block, use the keyword "Finally" and put > the code after it. The last line of the try block is "End Try" > > try > ' Protected Code > catch fEx as system.FileException > ' File errors > catch ex as Exception > ' All other errors > Finally > ' clean up code - release file handles, etc. > end try > > At any time, you can nest try...catch...[finally]...end try blocks, even > inside a catch or finally handler. An easy way to start converting is to > find your On Error Goto statement and replace it with Try. At the error > label, replace this with Catch ex as Exception. At the end of the > routine, > insert an End Try. If you have a resume statement, replace it with > "Finally" (before the end try) and move the code from the resume target > into > the finally block. > > For example - > > sub MySub() > On error goto myErr > ' Protected Statement > > ResumeHere: > ' Clean up code > exit sub > > myErr: > ' Error Handler > resume ResumeHere > end sub > > becomes > > sub MySub() > Try > ' Protected Statement > > Catch ex as exception > ' Error Handler - note: you can use multiple catch statements, one for > each type of error you expect to have; If none of your catch statements > can > handle the error, it is automatically propagated up the call stack to the > next level of error handling. > > Finally > ' Clean up code > End Try > end sub > > As for "On Error Resume Next", it's still useful, especially if you are > configuring an environment for your application and some parts of the > environment already exist and you would get an error back when you attempt > to configure previously existing parts. Keep these sections of code as > short as possible (I never need more than 10 lines under this type of > control). > > All uses of On Error Goto ... should be immediately replaced with try > blocks. > > Mike Ober. > > "fniles" <fni***@pfmail.com> wrote in message > news:%23mJdVj4pGHA.516@TK2MSFTNGP05.phx.gbl... >> Thank you all for your replies. >> In VB 6 at the top of a sub I used to put "on error goto err_routine", >> and >> in err_routine I will write the error to a file and do resume next, >> because the "resume next" is helpful during debuging a program, because I >> can put a break point on the Resume Next and when I hit F8 it will go to > the >> next code so that I know where the error occurs. >> >> In VB.NET where is the best place to put Try/catch, because if I put it > only >> for 1 line of code, it won't catch error on the other lines of code in > that >> same subroutine. >> So, I ended putting Try/catch at the top of the subroutine, and include > all >> the codes in that subroutine under "Try". When I get an error, even > knowing >> ex.message sometimes it is difficult to know which line of code causes >> the >> problem, and I would like to know which line is it that produced the > error. >> With resume next, I will be able to tell during debuging. >> >> Is there any way to do this ? >> >> "Marina Levit [MVP]" <someone@nospam.com> wrote in message >> news:OkfqsL4pGHA.4208@TK2MSFTNGP04.phx.gbl... >> > It's still there (unfortunately). >> > >> > You can say: On Error Resume Next. >> > >> > However, this does not work with try/catch. It's one or the other. >> > >> > My recommendation is to get rid of On Error Resume Next, and always use >> > Try/Catch in the appropriate places. Usually if an unexpected run time >> > error ocurred, you don't want to execute any more statements - so I > never >> > really understood why you would want to Resume Next. If an error > happens >> > that you were not expecting, you need to handle it, and get out >> > appropriately. >> > >> > "fniles" <fni***@pfmail.com> wrote in message >> > news:OAFzz63pGHA.3820@TK2MSFTNGP05.phx.gbl... >> >> In VB 6.0 in the error trapping, we can do "resume next" to continue >> >> on >> >> the next code. How can we do that in .NET with "Try", "Catch","End >> >> Try" > ? >> >> Thanks >> >> >> > >> > >> >> > > > I use multiple try catch statements to catch errors at the logical statement
level vs. the language statement level. Mike. Show quoteHide quote "fniles" <fni***@pfmail.com> wrote in message news:eh5UwzaqGHA.3648@TK2MSFTNGP03.phx.gbl... > Thank you for your reply. It is very helpful. > > >> For each section of code you wish to protect, put the keyword "try" > >> before > > it. > I really want to protect all codes in the subroutine, so replacing the "On > Error Goto" statement at the top of the sub with the Try is a good idea > (otherwise I will have to put "try/catch" everywhere in the subroutine) > The problem with this is, when I get an error, I really do not know which > section of the code the error comes from, while in VB6, with Resume Next > statement in my error label section, I can know which code it comes from. > > "Michael D. Ober" <ober***@.alum.mit.edu.nospam> wrote in message > news:dVCug.9141$PE1.4920@newsread2.news.pas.earthlink.net... > > You're struggling with one of the major differences between unstructured > > error handling (VB6) and structured error handling (VB.NET - all > > versions). > > In VB6, each Sub or Function could only have a single error block, which > > translated into additional, smaller, superflous, subs and functions to > > nest > > error handling. In VB.NET, you can have multiple, nested error handlers. > > Here's how to do it - > > > > For each section of code you wish to protect, put the keyword "try" before > > it. At the end of the protected code, put the keyword "Catch" with an > > exception type to handle. You can catch different types of exceptions for > > the same try block. Finally, if there is any clean up code that you need > > to > > execute before leaving the "try" block, use the keyword "Finally" and put > > the code after it. The last line of the try block is "End Try" > > > > try > > ' Protected Code > > catch fEx as system.FileException > > ' File errors > > catch ex as Exception > > ' All other errors > > Finally > > ' clean up code - release file handles, etc. > > end try > > > > At any time, you can nest try...catch...[finally]...end try blocks, even > > inside a catch or finally handler. An easy way to start converting is to > > find your On Error Goto statement and replace it with Try. At the error > > label, replace this with Catch ex as Exception. At the end of the > > routine, > > insert an End Try. If you have a resume statement, replace it with > > "Finally" (before the end try) and move the code from the resume target > > into > > the finally block. > > > > For example - > > > > sub MySub() > > On error goto myErr > > ' Protected Statement > > > > ResumeHere: > > ' Clean up code > > exit sub > > > > myErr: > > ' Error Handler > > resume ResumeHere > > end sub > > > > becomes > > > > sub MySub() > > Try > > ' Protected Statement > > > > Catch ex as exception > > ' Error Handler - note: you can use multiple catch statements, one for > > each type of error you expect to have; If none of your catch statements > > can > > handle the error, it is automatically propagated up the call stack to the > > next level of error handling. > > > > Finally > > ' Clean up code > > End Try > > end sub > > > > As for "On Error Resume Next", it's still useful, especially if you are > > configuring an environment for your application and some parts of the > > environment already exist and you would get an error back when you attempt > > to configure previously existing parts. Keep these sections of code as > > short as possible (I never need more than 10 lines under this type of > > control). > > > > All uses of On Error Goto ... should be immediately replaced with try > > blocks. > > > > Mike Ober. > > > > "fniles" <fni***@pfmail.com> wrote in message > > news:%23mJdVj4pGHA.516@TK2MSFTNGP05.phx.gbl... > >> Thank you all for your replies. > >> In VB 6 at the top of a sub I used to put "on error goto err_routine", > >> and > >> in err_routine I will write the error to a file and do resume next, > >> because the "resume next" is helpful during debuging a program, because I > >> can put a break point on the Resume Next and when I hit F8 it will go to > > the > >> next code so that I know where the error occurs. > >> > >> In VB.NET where is the best place to put Try/catch, because if I put it > > only > >> for 1 line of code, it won't catch error on the other lines of code in > > that > >> same subroutine. > >> So, I ended putting Try/catch at the top of the subroutine, and include > > all > >> the codes in that subroutine under "Try". When I get an error, even > > knowing > >> ex.message sometimes it is difficult to know which line of code causes > >> the > >> problem, and I would like to know which line is it that produced the > > error. > >> With resume next, I will be able to tell during debuging. > >> > >> Is there any way to do this ? > >> > >> "Marina Levit [MVP]" <someone@nospam.com> wrote in message > >> news:OkfqsL4pGHA.4208@TK2MSFTNGP04.phx.gbl... > >> > It's still there (unfortunately). > >> > > >> > You can say: On Error Resume Next. > >> > > >> > However, this does not work with try/catch. It's one or the other. > >> > > >> > My recommendation is to get rid of On Error Resume Next, and always use > >> > Try/Catch in the appropriate places. Usually if an unexpected run time > >> > error ocurred, you don't want to execute any more statements - so I > > never > >> > really understood why you would want to Resume Next. If an error > > happens > >> > that you were not expecting, you need to handle it, and get out > >> > appropriately. > >> > > >> > "fniles" <fni***@pfmail.com> wrote in message > >> > news:OAFzz63pGHA.3820@TK2MSFTNGP05.phx.gbl... > >> >> In VB 6.0 in the error trapping, we can do "resume next" to continue > >> >> on > >> >> the next code. How can we do that in .NET with "Try", "Catch","End > >> >> Try" > > ? > >> >> Thanks > >> >> > >> > > >> > > >> > >> > > > > > > > > > 
Other interesting topics
C.NET VS VB6
Using A Bound Dataset to insert new Seeking Design Advice ddl selectedindexchanged not firing on first item - I'm using a dataset to populate the ddl What's wrong with the combobox in grid programatically created checkboxes within panels again.... Dataset to excel DirectCast of object to interface doesn't work Why won't DateTimePicker work? Re: Strict type for Hashtable? |
|||||||||||||||||||||||
