On Sat, Apr 04, 2009 at 08:01:14PM +0200, Nicolas wrote: > By the way, for the try catch from vcard/vevent... > The patch is usefull only if AddRecord / SetRecord failed. > > builder function converts data to BlackBerry format, but if the result > isn't understood by the device (sample, the photo isn't correctly > encoded), AddRecord / SetRecord returns an exception. > So you exit opensync roughly... And you have to make a slow-sync. > In using this try/catch, I can ignore the error and skip the > vcard/vevent mal formed and avoid the slow-sync. > > It isn't very important, because we don't have to get error !
I guess I still don't understand why there is a difference. When you say that it exits opensync roughly, is the exception escaping from the plugin code, and causing the plugin to crash? I wrote in my other email: > The only difference in code paths, as far as I can see, is that if the > exception is caught in commit_change(), then osync_context_report_error() > reports OSYNC_ERROR_IO_ERROR. If CommitData() returns false, then > osync_context_report_error() reports OSYNC_ERROR_PARAMETER. > > Is this difference between error codes enough to cause a slow sync for you? With the additional try/catch, you return false in CommitData() and then it checks for false and returns an error to opensync. If there is an exception, it *should* be caught inside the try/catch in commit_change(), and return the same error to opensync, except for a different ID. If the Barry plugin is crashing due to an unhandled exception, then that's definitely a bug. - Chris ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
