Hi Kristis,
On Wed, Apr 14, 2010 at 23:27, Kristis Makris <[email protected]> wrote:
> On Sun, 2010-04-04 at 00:47 +0300, Yavor Nikolov wrote:
> > Hi Kristis,
> >
> > (1) Replacing bz_{lock,unlock}_tables with
> > bz_{start,commit,rollback}_transaction prevented the error from
> > occurring and seemed updating to RESOLVED FIXED worked fine. (I
> > haven't tested other scenarios).
>
> Is the use of "eval" in line 570, and of $@ necessary ? Could this be
> written more clearly ?
>
I agree that's ugly and I tried to figure out something nicer but I haven't
found a better solution yet (I'm not a big Perl expert). Not only it's ugly
but there is no easy way to do exception chaining and tracing call stack on
error is not possible if we attempt to "rethrow" the error.
Seems Bugzilla doesn't yet use the cleaner object-oriented exception
handling which has been introduced in recent versions of Perl. Maybe could
would look nicer if we implement some wrappers of Bugzilla api which are
wrapping errors into OO exceptions; and postponing error handling
(Integration.pm or Process.pm).
> If there is a possibility for Bugzilla to raise exceptions inside the
> eval {} blocks, is there another way of eliminating that possibility ?
>
I think If we use the WebService API error would be signalled in a bit
different manner. Another approach would be to patch Bugzilla.
>
>
> > * Looking at scmbug Bugzilla.pm tracker code (and the modified method
> > in particular) - things are getting much bloated with these many
> > version-specific if/else if cases. I just wonder - wouldn't it be
> > better to just refactor version-specific code as separate sub-classes
> > (the right one instantiated by Daemon depending on specified version;
> > or on specified class name)? That would make things look simpler and
> > easier to maintain - at least for the most recent bugtracker versions.
>
> It would be better in some respects. I don't currently consider the
> if/else cases to be a problem.
>
>
_______________________________________________
scmbug-users mailing list
[email protected]
http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
