Developers of Sympa

[David Verdin <address@concealed>]

Hi guys and sorry for this late answer,

Le 07/12/12 14:35, Guillaume Rousse a écrit :

address@concealed">I think we need a consistent plan about error management here...

There is a first discussion about error recovery.

There is little point in ensuring our codes survives and continue to run after any kind of error. A large class of such errors are due to developpement issues, for instance a missing parameter (provided the parameter list is not computed dynamically), or some type error after heavy refactoring. That's exactly the kind of error a statically typed language compiler would catch, but unfortunatly for us we have rely on testing (provided enough coverage), or runtime assertions, to do the same. I'm OK to consider those errors as unrecoverable (as unexpected, and fixables), and the current strategy of handling them gracefully through a top-level signal handler seems fine.

If we try to summarize what we can demand from an error handling workflow in Sympa, do we agree on the following?

1. in a sub, if anything in the processing prevents the sub from completing successfully, the sub must stop at once,
2. any such stop must produce a synthetic informational string that will be made available to the users,
3. if necessary, user data likely to be lost will be saved,
   
4. the calling context of a stopped sub will be informed of the stop
   
5. when a called sub stops in such conditions, the calling context will never be forced to stop by the called sub. The calling context is the only one to know whether it must stop now or not. If such decision is taken, the steps 1 to 4 will be performed once again by the calling context.
   

What we need indeed is that Sympa, in case of unrepairable error, holds whatever data it was holding, reports the error and goes on to the next request. Don't crash because, for some reason, we could not get the From field in a message.

Carp modules are useful but what do they do that we don't do yet?
When we raise an error, we return undef and log. The 'err' log level now adds a stack trace, so it is more or less the same as confess, but we don't kill the process.

About the three advantages you point:

1) no more "everything requires the Log module because every piece of code has to report its error itself", which plays a large part in current cross-dependencies deadlock

Unfortunately, I have no solution for this. that's actually an argument for Carp

2) easier unit-testing, as the caller code knows what is the error, instead of just being noticed an error occured

I don't see how unit-testing will be improved. Do the Carp subs return an error code or something?
Finally, error handling, in some cases is done by returning structured data (a hash in which an "error" key was set, for example). You can't do that with Carp.

3) better synthetic error messages.

Not really. Two subs are separated fo a reason. Logs are supposed to explain the context in which an error occurs. In your example, the calling sub could probably improve its log to explain what was the prupose of file rights change.

In conclusion, I'd like to balance the risk of seeing Sympa crash for an unvalid reason to be balanced with the value added by thye usage of Carp.

I'm really found of killing processes on development time, because it help us find bugs. In production, this is not the solution, I think. This would incline me to ban Carp module from Sympa. Except if, in each main loop of a Sympa daemon, we enclose the calls with eval. This way, no dameon could die, I think.

Cheers,

David

Attachment: smime.p7s
Description: Signature cryptographique S/MIME