>There seem to be a few miscellaneous conversion bugs left in an application that is now in production. I am unable to reproduce the errors.
>
>I have a general purpose terminal error handler class that looks like this :
>
>
>Friend Class ThreadExceptionHandler
> Public Sub Application_ThreadException(ByVal sender As System.Object, ByVal e As ThreadExceptionEventArgs)
> 'Display Message for the user that the program is going south
> 'Log the error
>
> Dim ex As Exception = e.Exception
> c = e.Exception.Message
> c = c & vbCrLf & "sender : " & sender.ToString
> c = c & vbCrLf & Environment.GetEnvironmentVariable("username") & " op " & My.Computer.Name
> c = c & vbCrLf
> c = c & vbCrLf & ex.ToString
>
> ' send myself an email with c in the boddy
>
> Application.Exit()
>
> End Sub
>
>
>End Class ' ThreadExceptionHandler
>
>
>This class is invoked as follows
>
> Dim handler As ThreadExceptionHandler = _
> New ThreadExceptionHandler()
> AddHandler Application.ThreadException, _
> AddressOf handler.Application_ThreadException
>
>
>This approach works very well for most of the crucial errors, but for conversion errors that can happen anywhere and are difficult to reproduce, the information one gets is a bit sketchy.
>
>I've been thinking of creating a static class with static properties that would give me clues about where error occurs and/what causes the error. The vales of those properties (last_method_called for example) would be set to the name of methods that I suspect and/or to the key.values (last_value_of_object_X) of certain objects.
>
>I'm not too hot about this approach considering the dependencies all this would create. Is there a better approach to this kind of problem (other than avoid this kind of conversion problems early :) )?
>
>Thanks in advance.
What information are you trying to get that is not in the ThreadExceptionEventArgs Exception ?
I'm assuming that you have Option Strict on (which should catch possible conversion errors at compile time) ?