New answers tagged


I suggest looking at event data aggregators like Segment which can send data to both your backend and several analytics services at the same time. This would provide a solve for both your purposes without duplication of event logging in your code.


I usually hit three major concerns when building analytics systems. How lossy can the analytics event set be? For example ad blockers tend to block most third party in-browser analytics. Depending on your audience that can be more than 20% of your site visitors. On the other hand more reliable events can impose real performance costs on your systems. How ...


Do not think about logging as "I want to log this data" think of it as "I have an event that may be interesting to somebody." The fact that 99% of the time the interested party is an object that takes logging events and then writes to a disk-based log is irrelevant to that mindset. Logging is essentially a producer-consumer event framework What you should ...


The main concern I have found with logging close to the source is that you are in danger of logging the same errors twice. In the second case we might imagine someone calling DoSomethingElse() without being sure whether it would log the error. These cases become increasingly common as the size and complexity of the component increases, and the number of ...


Main adventage of second solution ( pass errors up ) is: when you run mutiple functions in row that can throw errors, you don't have to make if for each one, but you can just do one if on higher level. And this solution is also encouraged on Go lang blog ( Simplifying repetitive error handling section ).

Top 50 recent answers are included