I'd also like to see all errx() calls removed and handled more
gracefully, for my use I've updated all of these to just err() and then
call mcm_server_deactivate() right after and return an error code.
Yeah, they're a rather sore spot for me too.
It's unacceptable for a memcache error to cause my entire application
to
exit unexpectedly. No error could be serious enough for this as the
application can still function 100% (albeit with a big performance hit)
without the cache working at all.
Yup. I want to do what I've done with the memory context functions,
except for with error/warnings. The goal being that if they're null,
it's a no-op, whereas if they're non-null, they'll fire off with your
custom error handling routines. For now, I'd just delete the offending
lines (not the answer I want to give, but i need to spend a tad more
time on this to do it right than I have, nevermind it'd take an ABI
change, which I'm going to hold off on doing until 1.3.0).
I'm guessing you are probably in agreement, and just haven't gotten
around to adding better handling for these conditions yet?
Complete agreement. warn()/err() are handy when developing something,
but don't belong in a library. I can see calling abort() on egregious
failures inside of the library, but not for normal use cases. -sc
--
Sean Chittenden
