[debpool] Logging and error handling

Magnus Holmgren holmgren at lysator.liu.se
Wed Apr 11 10:23:56 UTC 2007


This is the second major question to discuss, I believe, after the "database 
rebuild" question.

I had a look at bug #293054: An email notification feature would be nice, and 
tried to figure out how to gather useful information to put in a notification 
message, especially in the case of rejection. My feeling was that useful 
information is sent to the log in the various subroutines and not gathered so 
that it can be passed back to the user. Helper routines should generally log 
only DEBUG and possibly INFO level messages.

Also, the module-global-specific $Error variables are not particularly 
beautiful.

I think DebPool could benefit from eval/die. It would allow error messages to 
be passed back more easily, and many instances of checking the return value 
of a function call, only to set $Error to the other module's $Error and 
return 0 if the function call was unsuccessful, would go away. We could even 
be advanced and use references with die; this allows us to pass multiple 
separate lines of error messages if needed; other information can also be 
passed separately.

Some other details:

It should be possible to configure a log level; log messages with a severity 
below that log level would not be logged. That means that we need to give the 
current log levels numerical values.

REJECT should be a severity (between WARNING and ERROR) instead of a facility, 
as evidenced by the fact that all REJECT messages currently have a severity 
of ERROR and the fact that any WARNING message corresponding to a 
REJECT/ERROR one has to use a different facility. The semantics I suggest are 
that ERROR means that a more or less unexpected error occurred in processing 
(server errors, e.g. couldn't run gpg or failed to move files to the pool, 
similar to the HTTP 500 class of status codes), while REJECT means that the 
upload was unacceptable due to files missing or MD5 checksums wrong (client 
errors, similar to HTTP 400 status codes). Possibly one or two more 
facilities need to be defined (actually, all of them need to be 
well-defined).

-- 
Magnus Holmgren        holmgren at lysator.liu.se
                       (No Cc of list mail needed, thanks)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/debpool-devel/attachments/20070411/fde1c672/attachment.pgp


More information about the Debpool-devel mailing list