err.raise in ActiveX component - newbie 
Author Message
 err.raise in ActiveX component - newbie

Here's a VERY BASIC question that I'm sure someone can answer easily.

Say I have an ActiveX .dll that accesses a db through ADO (or does anything
else, for that matter). Under certain conditions I naturally want to raise
an error back to the caller using a simple standard technique as follows:

'MyClass

Public Enum mcErrors
    mcNoUserFound = vbObjectError + 512 + 1
    mcSomeOtherProblem = vbObjectError + 512 + 2
    '....
End Enum

Public Function ValidatedUser(ID As Long, Password As String) AS Boolean

    On Error GoTo Handler
    '.................
    'connect to database
    'get user details from db
    '.................
    If (rsUser.BOF AND rsUser.EOF) Then
        err.raise mcNoUserFound, "MySource", "MyDescription"
    ElseIf rsUser.Fields("Password") <> Password Then
        'bad password
        ValidatedUser = False
        GoTo Exiter
    Else
        'fill out object properties

        mstrPhone = (123) 456-7890
        'etc.
    End if

Exiter:
    'clean up
    rs.close
    'etc.
    Exit Function

Handler:
    err.raise err.number, err.source, err.description
    Resume Exiter

End Function

++++++++++++++++++++

Okay, so far so good. Some other program can instantiate the object, call
the method, and trap any errors using the enumerated error constants. But
here's my question: None of the code in my component following the line
where the error is raised APPEARS to run. Is that true? If I'm wrong about
this, how do I prove to myself that the code is really finishing up? On the
other hand, if execution is really suspended there, what happens to my
component? Doesn't this raise serious issues about cleaning up db
connections, releasing resources, etc.? How is this dealt with? Does it
depend on the caller explicitly destroying its instance of my component? All
the literature says not to depend on all resources and connections just
going away automatically when an instance of a component goes out of scope o
r whatever. What am I not getting here?

Thanks!

- Tony

Tony Scilipoti
*****************
Applications Development Lead
Brigham Surgical Group
Massachusetts, USA



Tue, 24 Jul 2001 03:00:00 GMT  
 err.raise in ActiveX component - newbie


Quote:
> Here's a VERY BASIC question that I'm sure someone can answer easily.

> Say I have an ActiveX .dll that accesses a db through ADO (or does anything
> else, for that matter). Under certain conditions I naturally want to raise
> an error back to the caller using a simple standard technique as follows:

> 'MyClass

> Public Enum mcErrors
>     mcNoUserFound = vbObjectError + 512 + 1
>     mcSomeOtherProblem = vbObjectError + 512 + 2
>     '....
> End Enum

> Public Function ValidatedUser(ID As Long, Password As String) AS Boolean

>     On Error GoTo Handler
>     '.................
>     'connect to database
>     'get user details from db
>     '.................
>     If (rsUser.BOF AND rsUser.EOF) Then
>         err.raise mcNoUserFound, "MySource", "MyDescription"
>     ElseIf rsUser.Fields("Password") <> Password Then
>         'bad password
>         ValidatedUser = False
>         GoTo Exiter
>     Else
>         'fill out object properties

>         mstrPhone = (123) 456-7890
>         'etc.
>     End if

> Exiter:
>     'clean up
>     rs.close
>     'etc.
>     Exit Function

> Handler:
>     err.raise err.number, err.source, err.description
>     Resume Exiter

> End Function

> ++++++++++++++++++++

> Okay, so far so good. Some other program can instantiate the object, call
> the method, and trap any errors using the enumerated error constants. But

Tony,
By executing err.raise all processing stops and the function exits and
control is returned to the calling procedure.
Your best bet is to do your cleanup code before you execute err.raise.

Good luck!

Mike



Wed, 25 Jul 2001 03:00:00 GMT  
 err.raise in ActiveX component - newbie
Firstly its fine for your component to have some error handling and I would
expect that, if you want to pass those errors through to the client then set
up a Connection Point Interface ( a callback interface) on your component,
this opens up all sorts of possibilities for communication between the
client and yourself, including the ability to send messages async.

a: Client creates an instance of your server
b: Client passes you an Interface  (  The clients callback interface )
c: You've probably registered the client if not register the client and
store the Interface
d: When you want to inform the Client of errors etc use the appropriate
clients Interface you stored to communicate.

Quote:

>Here's a VERY BASIC question that I'm sure someone can answer easily.

>Say I have an ActiveX .dll that accesses a db through ADO (or does anything
>else, for that matter). Under certain conditions I naturally want to raise
>an error back to the caller using a simple standard technique as follows:

>'MyClass

>Public Enum mcErrors
>    mcNoUserFound = vbObjectError + 512 + 1
>    mcSomeOtherProblem = vbObjectError + 512 + 2
>    '....
>End Enum

>Public Function ValidatedUser(ID As Long, Password As String) AS Boolean

>    On Error GoTo Handler
>    '.................
>    'connect to database
>    'get user details from db
>    '.................
>    If (rsUser.BOF AND rsUser.EOF) Then
>        err.raise mcNoUserFound, "MySource", "MyDescription"
>    ElseIf rsUser.Fields("Password") <> Password Then
>        'bad password
>        ValidatedUser = False
>        GoTo Exiter
>    Else
>        'fill out object properties

>        mstrPhone = (123) 456-7890
>        'etc.
>    End if

>Exiter:
>    'clean up
>    rs.close
>    'etc.
>    Exit Function

>Handler:
>    err.raise err.number, err.source, err.description
>    Resume Exiter

>End Function

>++++++++++++++++++++

>Okay, so far so good. Some other program can instantiate the object, call
>the method, and trap any errors using the enumerated error constants. But
>here's my question: None of the code in my component following the line
>where the error is raised APPEARS to run. Is that true? If I'm wrong about
>this, how do I prove to myself that the code is really finishing up? On the
>other hand, if execution is really suspended there, what happens to my
>component? Doesn't this raise serious issues about cleaning up db
>connections, releasing resources, etc.? How is this dealt with? Does it
>depend on the caller explicitly destroying its instance of my component?
All
>the literature says not to depend on all resources and connections just
>going away automatically when an instance of a component goes out of scope
o
>r whatever. What am I not getting here?

>Thanks!

>- Tony

>Tony Scilipoti
>*****************
>Applications Development Lead
>Brigham Surgical Group
>Massachusetts, USA




Wed, 25 Jul 2001 03:00:00 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. err.raise in COM components causing Error 438 in client

2. Problems when using Err.Raise in a public method of an activex

3. Problems when using Err.Raise in a public method of an activex

4. Problems when using Err.Raise in a public method of an activex

5. Err.Raise in OLE Server EXE not raising error in calling program

6. Err.Raise - error not being re-raised all the way to top of the call stack

7. Capturing an event in MSIE raised by an ActiveX component

8. Err : ActiveX component can't cretae object

9. DCOM Problem - Err 429 ActiveX Component can't create Object

10. Err.Raise Causes Automation Error

11. Raising Err in Class Module

12. Err.Raise Number starting point

 

 
Powered by phpBB® Forum Software