VB error handling

[Adron]

try/catch exists in C++ too, but I'm not switching languages. I have however written a little DLL which will capture unhandled VB errors and write a minidump. If anyone's interested, post, and I might publish.

[Grok]

try/catch exists in C++ too, but I'm not switching languages. I have however written a little DLL which will capture unhandled VB errors and write a minidump. If anyone's interested, post, and I might publish.

Hey I wrote one too, but mine is copyrighted.  Patent pending.  My lawyer is sending a C&D letter in the morning.  

[Skywing]

Adron, perhaps switch to VB.Net and try out their Try...Catch error system?  It's really nice for catching those forseeable or unforseeable bugs while using about 1/2 the code as you would on On Error systems used in VB 6.0.

You can't just switch a production system like that, especially one worked on by a team of programmers.  Customers won't like the added dependencies suddenly appearing without warning, either.

[DarkVirus]

Adron, perhaps switch to VB.Net and try out their Try...Catch error system?  It's really nice for catching those forseeable or unforseeable bugs while using about 1/2 the code as you would on On Error systems used in VB 6.0.

You can't just switch a production system like that, especially one worked on by a team of programmers.  Customers won't like the added dependencies suddenly appearing without warning, either.

I also wasn't aware of the context of what the program was even about or who was creating it. I thought it was a general topic about error handling. I also wasn't aware that Try...Catch was available in C++.

[Adron]

Well, the question was asked with a particular project in mind, which happens to be coded in VB (non-.NET). I would've preferred if it was coded in C++, which has better error handling in addition to everything else, but that would take too much time. So, I'm stuck with making the best of it!

At least it's not so difficult to write parts (like VBDump.dll) in C++ and call them from the VB parts.

[Adron]

Now, the wonderful vbdump Attach function returns a BOOL.

True - vbdump is attached
False - vbdump failed to attach

or

-1 - vbdump was already attached!

[Skywing]

Now, the wonderful vbdump Attach function returns a BOOL.

True - vbdump is attached
False - vbdump failed to attach

or

-1 - vbdump was already attached!

Ah, so it's another functions that actually returns a Troolean, like GetMessage.  Just what the world needs...

[Adron]

Yup!

But, it actually returns a "true", non-zero, value whenever it ends up being attached after call. Whether it was already attached or it attached during this call.

[Skywing]

Yup!

But, it actually returns a "true", non-zero, value whenever it ends up being attached after call. Whether it was already attached or it attached during this call.

I propose that we create a new type, TROOL, for this purpose.
#define TRUE 1
#define FALSE 0
#define MAYBE -1

[CupHead]

That's such a 2-bit data type.  *cough*

[Adron]

I'm currently working on the next version with non-fixed patch offsets for the messagebox in msvbvm*

Will be doing a search through the address space if I can't find a match at the known possible locations.