Enhancement to Logger (handle Error's in a more supportive way)

[ghost]

OpenUI5 version: all

Browser/version (+device/version): n/a

Any other tested browsers/devices(OK/FAIL): n/a

We're trying to use the jQuery.sap.log.* code (or the new sap.base.Log), which, for the most part, this works very well. But we have discovered that when an exception occurs, a Javascript error (maybe something undefined), only the message is captured by the logger.

Since all errors logged, are automatically sent to console.error, its understandable that the developer trusts the automatically included stacktrace. But this stacktrace is now wrong. When you know this, its just annoying and unhelpful. If you don't know it, time and hair is lost.

For me the core issue is where the error is forced to be a string: message : String(sMessage || ""), The object passed in, with its (valuable) stack trace, is lost.

If oLogEntry could include the original "message" (which could be an object), even if the logger code only wants a string, all listeners have a fighting chance to handle this differently.

Might not seem like much, but try changing all console.error messages in your code base to logger.error() and try tracking down an exception - you can't find the source of the issue in webtools any more, because the stacktrace is not the stacktrace you think it is.

This issue really becomes much worse when you throw promises into the mix. A common problem with promises is they often "catch" more than they should. E.g. A model update (using ajax) where many listeners are observing the model changes, catches an exception. However, the exception occurred in some utility class, indirectly referenced by one of the listeners! Without stack traces, it takes some time before you realise the model update code is perfect, the issue is in an entirely different place.

[Shtilianova]

Hello @srenwickblum , Thank you for sharing this finding. I've created an internal incident 1880717357. The status of the issue will be updated here in GitHub. Regards, Diana

[ecker]

Hi @srenwickblum, thanks for your input. It would indeed be helpful to provide better debugging capabilities, particularly by more useful stacktrace information. We had started to look into such improvements, but would need more time to catch-up, so currently we can't say if and when there's an improved stacktrace available.

[codeworrior]

BTW: Something into the direction of this enhancement request has been implemented with 429f584d86e83e20ea67aa0940e079e0d780d3ba . The methods of sap/base/Log.js now allow to specify an error object as sDetails parameter (2nd parameter). We first wanted to gather experiences with that approach before making it a public feature.

We are not fully satisfied with that approach yet as in Chrome it results in double stack traces (which pollutes the console a bit).

[ghost]

I have overridden the Log.error function to accept either a string or an error object. If its an error object, I write it to console.error as well. This works pretty well but overriding this function was a little hacky, I'll be glad to remove it when I can.

[flovogt]

Sorry for not responding so long on this issue here. We will have a deeper look in backlog item CPOUI5FOUNDATION-1016.