Question General beginner question on Exceptions

[vbDave]

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.

 

[Herman]

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.

 

[Herman]

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.

 

[jmcilhinney]

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