[prev in list] [next in list] [prev in thread] [next in thread]
List: subversion-issues
Subject: [Issue 3375] New - ra_serf desperately needs an error handling
From: "C. Michael Pilato" <cmpilato () collab ! net>
Date: 2009-02-27 16:23:28
Message-ID: iz3375 () subversion ! tigris ! org
[Download RAW message or body]
http://subversion.tigris.org/issues/show_bug.cgi?id=3375
Issue #|3375
Summary|ra_serf desperately needs an error handling overhaul
Component|subversion
Version|trunk
Platform|All
URL|
OS/Version|All
Status|NEW
Status whiteboard|
Keywords|
Resolution|
Issue type|DEFECT
Priority|P1
Subcomponent|libsvn_ra_serf
Assigned to|issues@subversion
Reported by|cmpilato
------- Additional comments from cmpilato@tigris.org Fri Feb 27 08:23:26 -0800 2009 -------
libsvn_ra_serf has quite possibly the worst error handling logic (illogic?) of
any piece of Subversion code ever. svn_error_t's are generated in multi-various
places, returned in various ways, sometimes *stuffed into the session baton for
future handling!*, and so on. Sometimes these errors are actually handled.
Sometimes not. If you never encounter errors while using the library, it all
works great. But when you do ...
Besides just needing a complete overhaul in its error handling mechanisms, the
library could stand an overhaul of its error *generating* mechanisms. It's
pretty common to see error strings like "OPTIONS request failed to return blah
blah blah" when no OPTIONS request was made in nearby code. (I suspect these
are mostly copy-n-paste-o's.)
This library must not be released as the default as long as it continues to leak
errors as easily as it does.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=463&dsMessageId=1239633
To unsubscribe from this discussion, e-mail: [issues-unsubscribe@subversion.tigris.org].
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic