haskell-distributed
Dispaly error message when closure in undesirializable
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.
Tracing does show it. But I think @Shimuuar is asking for a heads up in stderr with no tracing enabled.
Yes it's clearly a programmer error so failure should be loud. Now you need to specifically enable tracing and look for problems there.
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.
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.
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?
perhaps we want to selectively trace things instead
Indeed. That's what I mean with providing the ability to select only the evident errors to trace.
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...
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