I have created a vb.net program and released it to the customer. They are running the exe and at times the program crashes unexpectedly and display the message: "... has encountered a problem and needs to close"
I know I should have added code to handle the exception, but is there a way that I can find out which line in the program caused the error? What is generally as good way to track errors in a program after it has been released?
Thanks
for this kind of i-don't-know-where-to-look issue, i trapped exception at application level with the Application.DispatcherUnhandledException event :
http://msdn.microsoft.com/en-us/library/system.windows.application.dispatcherunhandledexception.aspx
and then in the event handler i get the StackTrace and display it in a MessageBox / dump it in a file, along with the exception.Message.
Next i offer the user the choice to re-launch the application.
Related
I have a function in vb.net that is shared. At one point it throws an error that says an 'open datareader already exists'. But this function is called from several different places in the program. How can I find out which part of the program called the function when it errors out?
You go to the Debug menu, show the Exceptions window, put a tick next to CLR exceptions and then run your program until it errors. As soon as the exception is raised VS will break, you will be able to see the call stack, and find out where the code was before. Note that this causes VS to stop on every exception, handled or not; it can become tedious to get to where you want to be - untick the "always break when this type of exception is thrown" in the exception helper if you just keep getting irrelevant exceptions breaking before this error you're trying to chase
It sounds like you're perhaps not creating/disposing of your DB access resources properly, especially if this is a static/shared context. Are you trying to reuse one DB connection? It wouldn't hurt to post the code of the faulting module
I am trying to develop a standard when I code applications.
I was curious as to what other developers did when it comes to sql errors or general program errors. Do you output the error to the screen, write to a log file, or something else?
It really depends on the severity of the error.
Is it a show stopper?
Can the software automatically retry and get away with no message?
Can it be ignored?
You can log every exception, or just certain ones, or none. I have a custom Exception class which logs every exception created (of that type).
I have an unhandled exception handler which emails me when there is one.
I'd only send a message to the user when it will change the way the application works from the user's point of view.
Your question is a bit subjective and you would get opinion-based answers if the entire community bothered to answer.
If the error is relevant and important to the user (e.g.: invalid username/password) display it to the user using a message box.
If the error is relevant to the developer, or can be used in the debugging process, use a log or a console output.
The trick is to identify which and how the errors should be displayed to the user. You don't want to bombard the user with exceptions and complicated errors on which the user has no idea on how to act upon.
Is it possible to have some sort of global action/event that triggers in the event of a fatal error? I'd like to be able to have my program write an error file and/or perform other "last breath" (no idea what else to call it...) action if a fatal or unhandled exception occurs that would cause the program to close or crash. Is such a thing possible?
I'm programming in VB.NET v4 using VS2010, if that is important. Also, all users of my app will be authenticated as an administrator (if that matters?).
It depends on what kind of application you're writing, but these may help:
Application.ApplicationExit
Application.ThreadException
AppDomain.UnhandledException
Yes there is AppDomain.UnhandledException Event. And no you do not need any permissions to use it.
Could someone provide info about error-handling in wxWidgets or a pointer to documentation?
Specifically, I discovered this behavior: I try to create a wxImage from a file. This is in an event-handler. The file is not present. The call to the image constructor does not throw an exception. (I understand that no wxWidgets code throws exceptions.) A call to image.Ok() returns false. Fine. But after my event-handler exits, wxWidgets gratuitously pops up an error message dialog. That's okay for this particular application, but I wonder how to stop that from happening if I want to handle the error myself. I suspect that the dialog is coming from an event-handler, but I search for things like EVT_ERROR, and came up empty.
There is the class wxLogNull for suppressing those log messages. See http://docs.wxwidgets.org/stable/wx_wxlognull.html#wxlognull where also an example is given.
Read the wxLog overview for more details on how wxWidgets handles this.
You can define your own log target which would throw an exception if an error message is logged. Of course, then you'd probably need to catch it in your event handler anyhow as you probably don't want to just give the user a relatively useless "File couldn't be opened" message but rather a "Image couldn't be opened" one. And if you do this, then why not just test for file.IsOk() directly and use wxLogError() yourself? IOW you can do what you want but I don't really see how is it better than the traditional exception-less way of doing things in this particular case.
've been running through the MSDN help documents to get a hang of Visual Basic. After trying out the example using timers --one drags a label and timer component into the designer and adds the following to the components subroutine
Label1.Text = My.Computer.Clock.LocalTime.ToLongTimeString
The output for the immediate window during debug is the following
A first chance exception of type
'System.InvalidCastException' occured
in Microsoft.VisualBasic.dll
A first
chance exception of type
'System.InvalidCastException' occured
in Microsoft.VisualBasic.dll
The same error occurs on a previous MSDN example using a context menu component. Should I Try...Catch...Finally this error and try to move on? Or, am I dealing with something much more serious?
When you see something about a first chance exception, it only means that an exception was caught within the code you called but does not necessarily mean that the code failed. If the code runs without causing your program to crash and returns a valid value, then do not have a problem. You will also see output in the debug window about first chance exceptions when you implement your own try/catch blocks.
In the Debug menu -> Exceptions, you can enable the debugger to stop when an Exception is first thrown, even if it would be caught later; if you want to find out what's happening, this is the easiest way to do it
In the first chance exception examine the details of the exception. You should see a stack frame/trace property. In there you should see what line the error occurs on. This should help you.
In the IDE try going to Tools > Options > Projects and Solutions > VB Defaults and setting Option Strict to 'On' - this may help catch casting problems when you compile your project rather than when you run it.
A 'first chance execption' does not necessarily mean you have a problem in your code. It could mean the IDE or the compiler or any other involved component encountered and handled an error and in the process the debugger is notified and the exception is being reported to the immediate window. This is an excellent post on the topic:
http://blogs.msdn.com/davidklinems/archive/2005/07/12/438061.aspx
A quick and easy solution for debug and diag of First Chance Exception is :
AppDomain.CurrentDomain.FirstChanceException += CurrentDomainOnFirstChanceException;
and then
private void CurrentDomainOnFirstChanceException(object sender, FirstChanceExceptionEventArgs firstChanceExceptionEventArgs)
{
if (firstChanceExceptionEventArgs.Exception is NullReferenceException)
{
// do your handling and debugging :)
}
}
Multiple First Chance Exception during the runtime can cripple the performance of your application because exception handling is expensive. Especially in web apps. You can add this handler and look at specific first chance exceptions and try to avoid/correct them.