Debugging and exceptions

[tg2003]

Hello all,

I have some questions about debugging my application:

1. When errors occur, I'm writing to a log file, so I have a public function makes the writing itself. How can I send the function/sub name to the log function, but not as a specific string text, but something more general? Is there any variable that holds the function name that I'm currently inside?

2. Can I make a generic "on error goto..." or "on error resume next" so it catches all exceptions of my application? I have many functions, and FAIK, I have to use "on error ..." for each function and subroutine.

Thanks in advance!

 

[tg2003]

In addition to my first question - Is there any variable that holds the line number that the error occured in?

This is very important if you try your application on machines that do not running VB ....

 

[jadams0173]

1. There is nothing that I know of inside VB6 that tells you what module you are in. I think you have to use (at least I do) a variable and set it for each particular procedure in your app and pass that variable to your error handler.

2. I've read that VB will go back up the call stack to find an on error goto statement, so I wouldn't think you could have a global on error goto statment. Maybe you load a hidden form that had an on error goto statment and keep it loaded and VB should go back up the the stack and find it. Just a thought/guess though.

 

[jadams0173]

You can use MZTools to put line numbers in your app. not sure about err.line capability

 

[jadams0173]

thread222-1487108 has your answer exactly to the line number the error was on.

 

[Andrzejek]

To know what line of code coused the error - use Erl, but you have to have the line numbers in your code - use MZTools for that.

Have fun.

---- Andy

 

[JoeAtWork]

Regarding your second question, as far as I know there is no way to make a "default" error handler.

The best solution I have come up for that is to use the Visual Basic Extensibility (I think that's what it's called) library to inject code at the bottom of every subroutine and function to call a global error handler.

Joe Schwarz
Custom Software Developer

http://www.plandev.net

 

[tg2003]

Thank you all!

Now I use the MZ-Tools numbering and Erl.

I still have problem that it tells me the line number only, but not the function or module that has caused it. I have dozens of functions and a few modules, so I can't write each of them...

 

[tg2003]

Another question please - FAWK, there is no variable that holds the function or module name. Is there any variable that holds the filename? e.g: form1.frm, *.bas

 

[strongm]

Afraid not - well, not at runtime, anyway (and even at for design time you'd need to create an IDE extensibility add-in)

 

[HughLerwill]

>I have dozens of functions and a few modules, so I can't write each of them ...

You should not need to include error handling in all your Subs and Functions if you write your code with consideration for errors and avoid them happening wherever possible. Adding error handling to everything will increase .exe file size, and probably slow it down.

Concentrate on using local error handling in procedures where errors cannot always be avoided e.g. file handling. In such routines you can use plenty of line numbers and custom messages (spelling out the procedure name, error description, line number and problem solution if any) to help the user (and especially you when and if he calls for help).

Remember too that your actions after an error will differ depending on the procedure you are in, sometimes you may just want to log it, othertimes advise the user with a message, othertimes and more usefully seemlessly branch to other code which runs without error.

 

[Golom]

Have a look at this product.

It will insert line numbers and error trapping code into your application and create new code in a separate directory that you can compile. For a moderate sized application that I have (~33,000 lines of code) the size of the executable goes from about 3.2 MB without error trapping to 5.4 MB with error trapping.