Printable View
I am looking to trap errors which are not handled at the moment. I was under the assumption that this is possible, since it is in .NET I believe.
Reason for me asking this is because something I dont know what is triggering to give me a run time error which I cannot pin point to.
My project start up point is a main method in a module.
Thanks.
You can use ******* to help you pin point your error. Once you run it all you need to do is to check the logs to see where your program has been.
One question, You are getting runtime errors in the compiled exe? If you are did you create an installer package for the app or just copy the exe to another computer? If you just copied it please read Installer Problems
Thanks Randem, not installing the app may well be the case as I am trying to support this product but seems as though EXE was simply copied across.
But, still would like to figure out a way to trap errors.
If you run ******* on a COPY of your code you can put error trap and run trace code into the app. Run it you will see.
Would it be fair to assume you have the source code?Quote:
Originally Posted by tiger03
No. The ability to deal with unhandled exceptions is new to .NET. VB6 didn't have that capability built into it.Quote:
Originally Posted by tiger03
Is the run time error coming from the VB engine, as in "Type Mismatch", or a Windows error, as in "Memory could not be read"? This will be important in determining the right approach to take.Quote:
Originally Posted by tiger03
With VB errors you can use the tool like Randem linked to or one like it to automatically add error handling code to the app. Of course, you have to have the source code and recompile the app. Also you'll find doing this can be a pain in large apps although it can be quite useful in tracking down mystery problems in bloated apps.
Windows errors are more difficult but usually you can at least pin down the module where they're happening. Then it's usually a matter of finding object references that weren't released properly, bad API calls or buggy third party controls or DLLs.
With VB errors you can simplify the process of adding error handling, using relevant tools as bgmacaw said.
If you create a sub to actually deal with the errors (such as displaying messages, logging them to a file, or whatever you like) then you can use something like MZTools to easily add error handling code to each of the subs that might have an error.
To do that you just create a template, perhaps like this:
..where StandardHandler is the routine that deals with the errors.Code:On Error GoTo ErrorHandler:
{PROCEDURE_BODY}
Exit {PROCEDURE_TYPE}
ErrorHandler: '** Error handler **
Call StandardHandler("{MODULE_NAME}", "{PROCEDURE_NAME}")
'(in each routine, if needed, manually add code here to tidy up, eg: close files that were opened)
..then go to each sub/function you want to add error handling to, and press the "add errorhandler" button on the toolbar - it will add the template to the relevant parts, and automatically convert the {} bits for you.
Unfortunately it can't do everything - hence the comment in the last line of the template, where you need to add code to tidy up.
MZTools can also add line numbers to the code for you (for a single sub/function, or a whole file, or the entire project) at the click of a button. You can then use ERL to determine exactly which line had the error.
You can also use the Insert Procedure Names Add-In that you will find in my signature to add a variable that contains the procedure name in any or all prcedures that you want to track. It can be used by itself or in conjunction with the template that Si posted.