[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