Go Back

determine call stack

I am looking for a way to have a class constructor determine what program/subroutine/function called the constructor.
 

5 Answers
0   | Posted by Andrew Meyer to Synergy DBL on 10/18/2019 3:29 PM
Phillip Bratt
I'm reading your question a couple of different ways but if you need to find the stacktrace inside the constructor then you can use %err_traceback% which writes out the stack trace. That way you can see where the constructor was called from. Of course this is for error trapping within your class constructor and I wasn't sure from your ask if you needed this always or under certain conditions (like errors).

10/18/2019 7:13 PM   0  
Andrew Meyer
I am looking to get the info during run time under normal flow not due to an error. I was hoping to have a constructor that didn't need to be passed parameters but would still be able to determine what function or program had instantiated it.
It looks like it would be easier to simply have the programmer utilizing the class pass the name of the function in when they call the constructor.
My other thought was to use the xcall TRACEBACK([filename]) function, but then I would then have to read the contents back in and parse it.
 

10/18/2019 7:33 PM   0  
Best Answer chosen by Andrew Meyer
Steve Ives
Oops, you're right, and actually I think I'm the one who ultimately provided bum info here. Sorry Andrew and sorry Phil!

I believe the answer you're actually looking for is:
  
XCALL MODNAME(1,caller)

But I do find myself wondering why you would need to know that type of information? It seems to me that if you need to get context of some sort then passing that information in through a constructor parameter would be a far better solution than this, which essentially limits where the class can be used from to specific routines?
 

10/19/2019 1:36 AM   1  
Mark Vinten
I would imagine scenario's where you've created a constructor that doesn't provide a context of where it's from and you want to verify or log each routine that's being called at the time of the problem, not just the actual caller.  Having a full strack trace is a very vital functoin that I've used heavily in .NET and PHP worlds.

It also means that you aren't having to change a constructor's parameter list which can be essentially a breaking change. Having a basic context passed would speed things up as stack traces tend to be expensive but wouldn't always give you a full view of what is being called.

P.S. I know this is a delayed resposne, but I thought it worth giving an example.

11/11/2019 9:17 AM   0  
Andrew Meyer
Actually the XCALL MODNAME(1,prev_routine)
is exactly what I was looking for.

I have built the code as a set of subroutines instead of as a class with methods.
The basic problem we were looking to solve was dealing with data extract functions for web pages that were exceeding a time limit built into the web portal that would kill the processes if it exceeded that time limit.
The solution devised would allow the function to be cleanly exited if it was approaching this time limit and resubmitted as a detached process that would then email the results of the data extract back to the user who initiate the request.
This has been achieved using three subroutines, a "wrapper" program to recall the data extract function and minimal coding in the affected data extract functions.
Using the MODNAME function just reduces the number of parameters the programmer has to supply to the intialization function.
The result of the MODNAME is used to:
1. lookup the time limit for the particular function
2. Generate unique temporary working files and result files if running as a detached process
3. Helps define the name of the particular "wrapper" program to use to recall the data extract function.
The solution set allows us to reuse the business logic in the data extract function without a lot of re-coding. 

11/11/2019 12:07 PM   0  
Please log in to comment or answer this question.