When "throwing application errors" in VisualBasic (prior to .Net / version 7)...
On the "Err.Raise" statements, it's good form to do
Err.Raise vbObjectError + <app_number>, ...where "<app_number>" is some application-defined error number.
This will prevent your error numbers from conflicting with system-defined error numbers.
"You create custom errors by using the VB built-in vbObjectError constant, then adding an offset. Microsoft reserves error values between vbObjectError and vbObjectError + 512, so you must start custom errors at offset 513 or greater. The vbObjectError constant is equivalent to hex value 80040000, which prints out as value -2147221504 if you display its decimal equivalent. Therefore, it's often convenient to display custom errors as hex values (using the Hex$ function), as shown in the ClassErr routine." -- Visual Basic Programmer's Journal, January 2001, Volume 11, Issue 1 -- see http://www.vbpj.com
This is still fully supported in VisualBasicDotNet, but it's NOT the recommended way of doing exception handling in the DotNet environment: "StructuredErrorHandling?", in the C#/Java "try-catch and throw" style is the recommended way of handling error exceptions in the DotNet environment.
Can you explain the reason why you'd want to raise an error with a particular number? If it gets displayed to a user, an error number means approximately nothing. The description is where meaning should be conveyed.
For errors that will be displayed to a user, sure. However, if you're writing some library code and you need to signal an error condition to the calling application, then a number will often be easier for it to deal with than a textual message. The Err.Raise statement is VB's interface to the standard HRESULT error handling in COM (ComponentObjectModel).
I think we should differ between public and private errors. With private I mean errors you don't see outside of your ActiveX component. I usually don't care much about the number and often use 999. The description field can contain any string, so we could use it to transfer xml or some other encoded values. As soon as the number means anything I would use vbObjectError + whatever constant.
The most important thing is not to use anything which VbClassic or system components reserves.
-- ThomasEyde
[Seen on StackModuleInVbClassic]