Results 1 to 4 of 4

Thread: General beginner question on Exceptions

  1. #1
    vbDave is offline VB.NET Forum Newbie
    .NET Framework
    .NET 3.0
    Join Date
    Jan 2010
    Location
    Illinois
    Posts
    2
    Reputation
    0

    General beginner question on Exceptions

    I'll keep my 'apology' short but need to state that I am a part-time programmer just now transitioning to VB.NET from VB6. For my first step into VB.NET I have a 50,000 line program I am converting from VB6 to VB.NET. I now have it mostly running, just now starting the test and debug phase.

    My question is basic and has to do with exceptions in general. Am I safe is assuming that if an exception is shown in the debug window but doesn't halt the program operation that it will not cause problems when I compile and deploy on my customer's PC? Certainly, I plan to try to look into as many exceptions as I can. I am assuming that all the exceptions that are being listed in the debug window are being handled by my existing VB6 error handling. I plan to implement Try-Catch where it makes sense but I'd like to avoid making sweeping changes just for the sake of change to the newer error model.

    This is a time sensitive deployment and I'll be very nervous if I discover that I still have a huge effort ahead of me in either converting my error handling or finding that the exceptions that don't currently impact the program operation in development mode will haunt me after I compile and deploy.

    My next step is to figure out how to package and deploy. The application is only on one other PC but my customer is 200 miles away. But's that's another story, another thread.

    Thanks in advance for any help, tips and comments.

    PS - this was a rather painful process. The VB6 update wizard handled a tiny bit but I'm guessing I manually modified 5,000+ lines. Huge changes req'd when I replaced the now-obsolete third party controls.

  2. #2
    Herman is offline VB.NET Forum Idol
    .NET Framework
    .NET 4.0
    Join Date
    Oct 2011
    Location
    Montreal, QC, CA
    Posts
    866
    Reputation
    1213
    My question is basic and has to do with exceptions in general. Am I safe is assuming that if an exception is shown in the debug window but doesn't halt the program operation that it will not cause problems when I compile and deploy on my customer's PC?
    Well, define "safe"... Some exceptions are expected, and handled properly, and those will still show in the debug window. Exceptions themselves are not a problem, they are just signposts telling what is wrong with the code execution and where.

    Certainly, I plan to try to look into as many exceptions as I can. I am assuming that all the exceptions that are being listed in the debug window are being handled by my existing VB6 error handling. I plan to implement Try-Catch where it makes sense but I'd like to avoid making sweeping changes just for the sake of change to the newer error model.
    VB6 didn't really have proper error handling... You should definitely NOT keep any On Error Goto Whatever. You should really embrace the new error model, it will make your life 1000x easier. Exceptions are there for you to use... For example:

    Public Sub SomeSub()
    DoSomethingFirst

    Try
    DoSomethingWithError
    Catch ex As ArgumentException
    ' Here we catch only ArgumentExceptions
    Catch ex As InvalidOperationException
    ' Here we catch only InvalidOperationExceptions
    Catch ex As Exception
    ' Here we catch any other exception
    Finally
    ' Here we can run some code afterwards no matter if there was an exception or not
    End Try
    End Sub


    Proper error handling is very easy, especially when converting, and is probably one of the first things you should understand about .NET. The other HUGE advantage is that you can check individual parts of a procedure independently, without having to On Error Resume Next or the Goto 0 nonsense. Wherever you suspect you might run into an exception that you can handle manually, you add in a Try Catch block. Do NOT however add them willy nilly without ever handling them. If you won't handle it it's better that you leave the exception unhandled, so that you may debug it properly.

    As far as the effort required, the problem is that you used the converter in the first place, and tried to translate each line individually. It is much easier and faster to figure out what a procedure does, its inputs, outputs, and constraints, and just rewrite it properly in .NET. Of course that implies that the conversion is being done by someone who at least has some experience in .NET. As for third party controls, it's always the same story, and exactly why they are often a bad idea. In VB6 you didn't have much of a choice, because there was no easy inheritance model. In .NET if you want a special CheckBox, you Inherits Checkbox and implement your custom functionality.
    Last edited by Herman; 10-23-2013 at 4:39 PM.

  3. #3
    Herman is offline VB.NET Forum Idol
    .NET Framework
    .NET 4.0
    Join Date
    Oct 2011
    Location
    Montreal, QC, CA
    Posts
    866
    Reputation
    1213
    Just wanted to add, depending on which controls you used and how, you should in theory be able to replicate the previous control's behavior by extending standard controls. Of course it can get messy fast if you were using it to a greater extent, in which case there is a good chance the previous control's author have a .NET version with similar functionality.

  4. #4
    jmcilhinney's Avatar
    jmcilhinney is offline VB.NET Forum Moderator
    .NET Framework
    .NET 4.0
    Join Date
    Aug 2004
    Location
    Sydney, Australia
    Posts
    13,813
    Reputation
    1707
    One thing that you should also do is ensure that you handle the UnhandledException event of the application. In the event handler, you can log the exception and close or restart the app. That will help you fix any issues that you missed.

    Note that it can never be guaranteed to be safe to continue if an unexpected exception is thrown, because you can't anticipate the application state if you didn't anticipate the exception. It might actually be safe to continue though, so you might want to give your users the option. Here's how I did that here:
    Imports Microsoft.VisualBasic.ApplicationServices

    Namespace My

    ' The following events are available for MyApplication:
    '
    ' Startup: Raised when the application starts, before the startup form is created.
    ' Shutdown: Raised after all application forms are closed. This event is not raised if the application terminates abnormally.
    ' UnhandledException: Raised if the application encounters an unhandled exception.
    ' StartupNextInstance: Raised when launching a single-instance application and the application is already active.
    ' NetworkAvailabilityChanged: Raised when the network connection is connected or disconnected.
    Partial Friend Class MyApplication

    Private Sub MyApplication_UnhandledException(ByVal sender As Object, ByVal e As UnhandledExceptionEventArgs) Handles Me.UnhandledException
    Using dialogue As New frmUnhandledException(e.Exception) With {.StartPosition = FormStartPosition.CenterParent}
    Select Case dialogue.ShowDialog()
    Case DialogResult.Retry
    'Restart
    e.ExitApplication = False
    Windows.Forms.Application.Restart()
    Case DialogResult.Abort
    'Exit
    e.ExitApplication = True
    Case DialogResult.Ignore
    'Continue
    e.ExitApplication = False
    End Select
    End Using
    End Sub
    End Class

    End Namespace

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •