[xd]

"making one HTTP post for every error is very wasteful."

We implemented this where I work many years back, and as long as you are keeping on top of the errors this isn't a problem.

If you are having to buffer your errors before sending them off to be logged because you are noticing a drain on your resources, you're doing it wrong.

[rakeshpai]

You aren't wrong if you are looking at the server's resource consumption. However, the need to buffer the errors is so that we can minimize network overhead, from the client's perspective. It's to reduce the number of HTTP connections, even if it means the payload is larger - much like why CSS sprites are a good idea.

[wpietri]

CSS sprites are a good idea because modern web pages have a zillion little icons. If you have a zillion little errors per pageview, I'm inclined to agree with xd: that's the sign of an underlying problem that should be fixed directly. Or if the errors are truly spurious junk, then I've just fixed that by not sending them over the wire at all. Is there some case that wouldn't cover?

[ivanhoe]

It's not very complicated to modify the logic to start buffering on a second error (the first one is sent immediately), and then flush errors to the server and repeat this logic every X seconds... it's just a matter of an extra flag in the error handler

[xd]

True, also come to think about it, I guess it would limit the damage a rouge loop spitting errors at the server would cause.