improve LogError #3843
improve LogError #3843
Conversation
For the usages inside Fyne, the actual caller line is not really helpful. Instead, the caller of the caller is interesting most of the time. For usages outside Fyne, it might be different. Therefore, we now log both.
|
Mea culpa … didn’t know that we actually have a test for the error logger :). |
|
I wonder if there perhaps is a better way to generate a stack trace (instead of using |
|
What this originally aimed to do was print the most likely like that caused a problem. |
|
I suppose you’re right. I’m not entirely sure about this change. Like you say, the initial implementation is nice because it prints the most likely error location. I was quite happy with the current behaviour of the logging. What this PR is trying to do seems to me like what you usually would use a debugger for. Or am I perhaps too old school in saying that (I’ve done way too much C++ recently)? |
|
I think log are for user report error and debugger are for developers. In this case, having a full stack report can sometime be useful, but not always. I would propose to either have the stack display when doing not doing a release build or when an environment variable is set. |
|
That sounds like a good plan. I'm definitely in favour of release builds (using that build tag) keeping the logging as is and debug builds providing more information. |
|
We also have a handy "debug" tag that is perhaps where a full stack report would live? |
Description:
This PR adds another line of context to
LogErroroutput. This is at least useful for all messages generated by Fyne itself because it does not help to know the location of the logging in Fyne but one needs to know the location of the caller of the logging Fyne method (maybe even further but that has to be proven).Checklist: