Log management for released apps


#1

Hi,

During development I’ve been logging errors and info messages (Console.log, Console.info, Console.error), without printing passwords or any other sensitive data.

I would to know if it’s ok to let those logs in my released app (Production) or if it’s a better practice to remove them and in that case if there is a way to keep the Console calls in the code without breaking the app.

Thanks.


#2

Remove console.logs because you do not need them in production. You can not debug production apps, yet. If you build apk or ipa with the keystores/certificates you are not allowed to debug.

In reality you would connect your app a error-tracking API --> sending an error report if a hard error occurs.

There is also the possibility of error tracking with google analytics.
https://developers.google.com/analytics/devguides/collection/analyticsjs/exceptions

connect your ga account and track an error with description, title and so on.
Like if your endpoint return 500 or something else.

It is not easy to track really javascript errors like syntax errors, because for that you need a watcher on the window error object like that:

window.onerror = function(error, url, line) {
  // ga track ({acc:'error', data:'ERR:'+error+' URL:'+url+' L:'+line});
};

#3

Hi,

Thanks for your answer :smile:
I checked some documentation and found that UglifyJS2 has an option “drop_console” that would help me to remove the “console.x” calls automatically.

Thanks again :thumbsup:


#4

Alternatively, use Angular’s $log service and log things you only need for development as debug so you can configure them to be off for a release.

It can occasionally be useful to see some logs for a release build if something doesn’t work.


#5

Thanks for the tip :smile:


#6

We have been using $log for debugging. Am I right in assuming that code gets “switched off” in release builds? Or is there some other to switch/configure that?


#7

Nope, it doesn’t magically switch itself off. You need to configure the $logProvider appropriately.


#8

heard some good things about tracking js errors with trackJS - https://docs.trackjs.com/