Repository navigation
Dispaly error message when closure in undesirializable #244
Description
When CH could not deserialize closure because some remote table were omitted it silently fails to spawn actor. This very puzzling behavior and it could take a lot of time to debug (it did). I think that error which could only occur in buggy program should be logged to stderr to make debugging easier.
Activity
hyperthunk commentedon Dec 23, 2015
Tracing would probably be an option...
facundominguez commentedon Dec 23, 2015
Tracing does show it. But I think @Shimuuar is asking for a heads up in
stderrwith no tracing enabled.Shimuuar commentedon Dec 23, 2015
Yes it's clearly a programmer error so failure should be loud. Now you need to specifically enable tracing and look for problems there.
hyperthunk commentedon Dec 24, 2015
I guess I see your point, but my general feeling is that spewing to stderr is a poor man's substitute for proper logging, which is what the tracing facility provides.
Perhaps always writing some management events to whatever configured trace targets are available (based on severity or some such, and dedicating to stdout/stderr) regardless of whether tracing is enabled, would be an alternative you'd consider?
I really don't want to litter the codebase with writing to stderr whenever we want a "loud failure", especially since the tracing APIs already provide a means for notifying interesting events.
facundominguez commentedon Jan 21, 2016
Perhaps a solution that makes everyone happy is to send trace messages by default to stderr.
Currently the default is to not send tracing messages anywhere at all.If flags do not provide enough granularity to select only those errors which are considered bugs, we probably should allow for that and make it a default. Or maybe, as Tim suggests, just trace them whatever the current flags are.
hyperthunk commentedon Jan 21, 2016
I'm not entirely sure about that. Tracing produces a tonne of info, perhaps we want to selectively trace things instead. Let me ponder for a day or two and suggest an approach?
facundominguez commentedon Jan 21, 2016
Indeed. That's what I mean with providing the ability to select only the evident errors to trace.
hyperthunk commentedon Jan 21, 2016
I think what we're getting into here is that murky territory that is in between tracing and logging. There is a very lightweight framework for logging in place, so maybe we should use that for this level of info/error messages? I'll dig out the code reference in a moment and post it...
hyperthunk commentedon Jan 21, 2016
Ah no, that code (SystemLog.hs) is in distributed-process-extras. We could migrate it, since the only things in its library that it depends on are a couple of type classes afaikt