Wish Runtime symbols for current sub and current line

[Alessandro71]

so we can have something like this in Release mode

Log($"error in sub ${CURRENTSUB} at ${CURRENTLINE}"$)

 

[Sandman]

Line would probably impact performance, but sub would be nice. And name of module.

 

[agraham]

I would guess that it is impractical to trace every call at runtime as the performance overhead and code bloat would be too much. There is however an ExceptionEx object in my Threading library that can give you the stack trace of the LastException and give you the module, method name and Java line number where it occurred.

EDIT: Apart from the above paragraph I deleted the rest of the original post as the code I posted didn't work as expected. I went back to the original Threading demo and THAT didn't behave as expected so I think that over time (Threading library goes back to the start of B4A) something has changed somewhere that breaks ExceptionEx. Sorry for the confusion.

EDIT2: It probably my memory that's got broken over the years. Using the stack trace in ExceptionEx is not as simple as I thought I remembered as if the error occurred in a library you need to walk the stack trace backwards to find the likely B4A method that called the failing method so in all it's not as useful as I thought that I remembered.

 

[Alessandro71]

Line would probably impact performance, but sub would be nice. And name of module.

they may be resolved at compilation time, so there would be no performance impact at run time

 

[Sandman]

Yeah, true. I don't know why I was thinking it would affect performance. But it would surely add quite a bit of bloat to the source, pretty close to what a debug builds looks like.

 

[agraham]

there would be no performance impact at run time

On further thought I'm not sure exactly what you have in mind. If CURRENTSUB and CURRENTLINE were resolved at compile time it could only resolve the Sub and line number of the Log statement itself and I can't see a use for that.

If compiled at runtime what would you expect them to then represent when invoked?

 

[Alessandro71]

I expect them to represent the sub and the line number where the identifier is used
their value can be even solved by the IDE itself
on a second thought, even CURRENTMODULE would be useful

 

[agraham]

I'm afraid that I don't see any use for that as you can easily put that information in the code yourself as you know what line, Sub and module you are presently coding.

 

[Alexander Stolte]

I'm afraid that I don't see any use for that as you can easily put that information in the code yourself as you know what line, Sub and module you are presently coding

So you change the line number in all subs every time if you add a new function above?

In .net we use log4net for logging and there is also the possibility to write the line number into the file, that speeds up the error search enormously.

 

[Alessandro71]

I'm afraid that I don't see any use for that as you can easily put that information in the code yourself as you know what line, Sub and module you are presently coding.

Yes, but not massively and programmatically.
my use case is a general purpose exception handling and logging sub

 

[agraham]

So you change the line number in all subs every time if you add a new function above?

OK I now see that. You have a point but I just don't see any use for it the way I code so it doesn't tick any boxes for me - but your coding practices are probably different.

 

[Alexander Stolte]

but I just don't see any use for it the way I code so it doesn't tick any boxes for me - but your coding practices are probably different.

Let me show you a line from our error logging:

2022-08-02 16:35:30,324 [1] ERROR - [mycompany.theproject.modFunctions - funcShowWaitIndicator] - [110] Message:Splash Form already shown

You look at it and know directly in which module the error occurred, in which sub and in which code line. So you can start directly at the right place to look for the error and add break points.

 

[Sandman]

Let me show you a line from our error logging:

2022-08-02 16:35:30,324 [1] ERROR - [mycompany.theproject.modFunctions - funcShowWaitIndicator] - [110] Message:Splash Form already shown

You look at it and know directly in which module the error occurred, in which sub and in which code line. So you can start directly at the right place to look for the error and add break points.

That looks amazing.

And let's be clear, it's not like we're introducing something not already in B4X. We already have the somewhat weird "sender" that isn't even an argument in the sub signature, it's just magically available. There's absolutely nothing, conceptually speaking, that would make CURRENTMODULE or CURRENTSUB stand out.

 

[Alessandro71]

Sender is a runtime object, CURRENTxxx tokens might just be preprocessor macros

 

[Sandman]

Sender is a runtime object, CURRENTxxx tokens might just be preprocessor macros

I'm not sure how that is relevant. I'm just discussing the developer experience using B4X.

 

[Sandman]

This whole thing could also be solved by the community if we hade a compiler step that allowed us to modify the source used for the compilation.