[AccessD] Handing error back down call stack?

[Ryan W]

Thanks Jim,
  I think this will be the way to go since BarFoo already handles and logs
some errors, but I need it to percolate up depending on how it's being
called.

  I'm settling for an Optional blRaiseErr parameter (set false by default)
and then if it's set true it traps the error code and description in
variables and raises the error since I don't want (or need) to change all
the calling code.

  On error goto -1 seemed to kill my err.raise when percolating up, though.
On error goto 0 right before my err.raise worked, however? Not sure if I've
got ordering wrong?






On Thu, Jun 16, 2022 at 9:07 AM Jim Dettman via AccessD <
accessd at databaseadvisors.com> wrote:

>
>  And BTW, if you need  BarFoo() to handle some errors with its own handler,
> but percolate up others, turn off the error handler with On Error Goto -1,
> then RAISE an error.
>
>
>
> https://docs.microsoft.com/en-us/office/vba/Language/Reference/user-interfac
> e-help/raise-method
> <https://docs.microsoft.com/en-us/office/vba/Language/Reference/user-interface-help/raise-method>
>
> Jim.
>
> -----Original Message-----
> From: AccessD On Behalf Of Jim Dettman via AccessD
> Sent: Thursday, June 16, 2022 10:00 AM
> To: 'Access Developers discussion and problem solving'
> <accessd at databaseadvisors.com>
> Cc: Jim Dettman <jimdettman at verizon.net>
> Subject: Re: [AccessD] Handing error back down call stack?
>
>
>  No active error handler in BarFoo.
>
>  It will percolate up to FooBar().  From:
>
> http://www.cpearson.com/Excel/ErrorHandling.htm
>
> Error Handling With Multiple Procedures
>
> Every procedure need not have a error code. When an error occurs, VBA uses
> the last On Error statement to direct code execution. If the code causing
> the error is in a procedure with an On Error statement, error handling is
> as
> described in the above section. However, if the procedure in which the
> error
> occurs does not have an error handler, VBA looks backwards through the
> procedure calls which lead to the erroneous code. For example if procedure
> A
> calls B and B calls C, and A is the only procedure with an error handler,
> if
> an error occurs in procedure C, code execution is immediately transferred
> to
> the error handler in procedure A, skipping the remaining code in B.
>
>
> Chip has a lot of good stuff BTW.   While he writes from the Excel
> Viewpoint, it's still applies to VBA and Access.
>
> Jim.
>
>
>
> -----Original Message-----
> From: AccessD On Behalf Of Ryan W
> Sent: Thursday, June 16, 2022 9:51 AM
> To: Access Developers discussion and problem solving
> <accessd at databaseadvisors.com>
> Subject: [AccessD] Handing error back down call stack?
>
> What's the best / ideal way to hand an error back down the call stack?
>
> Say I have
>
> Public Function FooBar()
> on error goto handler
>
>  call BarFoo
>
> exitroutine:
>  'cleanup code here
>  exit function
>
> handler:
>   msgbox err.number & " " & err.description & " in routine FooBar"
>   resume exitroutine
> End Function
>
> I want the error from BarFoo to come back to function FooBar so I can
> handle it there. As of right now the error handler in BarFoo throws the
> error but I need to catch it in the calling procedure.
>
> Right now it seems like if I trap the err.number and err.description into
> variables and Err.Raise those in my error handler in the called function
> might be the way to go?
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> https://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> https://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> https://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>