I have VB6 application , I want to put some good error handling finction in it which can tell me what was the error and exact place when it happened , can anyone suggest the good way to do this
相关问题
- How do I identify what code is generating “ '&
- Convert VB's Val to Java?
- Invalid Picture In Visual basic 6
- Advanced error handling: systematically try a rang
- Compile is really slow for a solution with many pr
相关文章
- <link> onerror do not work in IE
- Could not find default endpoint element that refer
- Reading (with Filesystem.FileGet) VB6 record file
- WPF- validation error event doesn't fire
- Trim all types of whitespace, including tabs
- What is the direct cause and source of the “Sorry,
- Codeigniter not logging
- Error: “Program type already present: androidx.ver
Use on
First of all, go get MZTools for Visual Basic 6, its free and invaluable. Second add a custom error handler on every function (yes, every function). The error handler we use looks something like this:
Then create a LogError function that logs the error to disc. Next, before you release code add Line Numbers to every function (this is also built into MZTools). From now on you will know from the Error Logs everything that happens. If possible, also, upload the error logs and actually examine them live from the field.
This is about the best you can do for unexpected global error handling in VB6 (one of its many defects), and really this should only be used to find unexpected errors. If you know that if there is the possibility of an error occurring in a certain situation, you should catch that particular error and handle for it. If you know that an error occurring in a certain section is going to cause instability (File IO, Memory Issues, etc) warn the user and know that you are in an "unknown state" and that "bad things" are probably going happen. Obviously use friendly terms to keep the user informed, but not frightened.
ON ERROR GOTO
and the
object.
There is a tutorial here.
a simple way without additional modules, useful for class modules:
pre-empt each function/subs:
handler/bubbleup:
voila, ghetto stack trace.
Yes, take Kris's advice and get MZTools.
You can add line numbers to section off areas of complex procedures, which ERL will report in the error handler, to track down which area is causing the error.
I use a home-grown
Error.bas
module to make reporting and re-raising less cumbersome.Here's its contents (edited for length):
Reporting an error is as simple as:
Reraising an error is as simple as calling
Error.Reraise
with the new source.Although it is possible to retrieve the
Source
andProcedure
parameters from the call stack if you compile with symbolic debug info, it's not reliable enough to use in production applications