Sven W.

I strongly disagree. Errors in the logging framework itself should also be propagated though the error stack.

First of all I use logger primarily to log ERRORS. Sometimes for tracing. For real debugging there are better tools. I never ever want that logger silently "forgets" to store...

@andyhardy How about if you simply write a wrapper around the logger.debug call, where you handle the error. Nobody prevents you from doing this. You would still run into the...

The suggestion from @jaughenbaugh depends on knowing the correct line of code and calling package. It is difficult to get this at runtime inside logger. Also the information depends on...

> @dgielis How do you think I should handle the following situation: > > Logger level is set to error (i.e. similar to production situation) > APEX developer logs in...

In 12c we can use utl_call_stack.DYNAMIC_DEPTH to provide that information. However since the logger internal calls adds to this number, it should be reduced by a few values.

The main problem is how to increase and decrease the stack depth. In one project I use code similar to this, to get the same result. ```sql g_trc varchar2(1000); --...

While I like the base concept, I think it is very situational. Meaning this will work only in some specific cases. For example it is not possible to run modules...

DBMS_UTILITY.FORMAT_ERROR_BACKTRACE holds the line number of the error. DBMS_UTILITY.FORMAT_ERROR_STACK still holds the last error message. I often concat the two to make sure I got everything.