Hi,<br><br>Kristis will explain best what he means - here are my comments below inline (since I'm the one intending to wrap bugzilla calls in eval block). Excuse me for my ignorance since I'm not a Perl guru (I just got involved to fix my problems as end user).<br>
<br><div class="gmail_quote">On Fri, Apr 16, 2010 at 02:24, Max Kanat-Alexander <span dir="ltr"><<a href="mailto:mkanat@bugzilla.org" target="_blank">mkanat@bugzilla.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div>On 04/15/2010 10:04 AM, Kristis Makris wrote:<br>
> How does bugzilla 3.2/3.4/3.6 handle errors with Bug::check() ? Does it<br>
> throw exceptions with die() ? Is this necessary ?<br>
<br>
</div> It calls ThrowUserError. By default this calls exit(), but you can<br>
switch to Bugzilla->error_mode(ERROR_MODE_DIE) before calling it (and<br>
then switch back to the normal error mode) if you'd like.<br></blockquote><div>We're calling this from separate perl application - not as CGI. So I believe error_mode is ERROR_MODE_DIE by default in our case.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
However, generally you shouldn't be calling things inside of an<br>
eval--there's always ways to check things for yourself. What<br>
specifically are you trying to do?<br></blockquote><div>Good to know if there are better alternatives. We have a daemon (perl application) which is integrating version control systems (e.g. Subversion) with Bug-tracking system (Bugzilla). So for example - on commit to version control we want to perform following with Bugzilla on behalf of the user performing scm commit (we have the mapping to the corresponding bugzilla username):<br>
- add comment to the bug (extracted from version control system commit message)<br> - update bugzilla bug status and resolution; or reassign bug<br> - send e-mail notifications to interested parties (that's my custom extension not yet in official scmbug release)<br>
- Some other checks and verifications (e.g. possible workflow transitions are extracted to signal some errors even before version control commit).<br>* And on error version control user is supposed to get appropriate error message (e.g. the given duplicate bug id is wrong; the new asaignee user is invalid; Lack of permissions to modify bug).<br>
<br><br>For example - consider following fragment of code:<br> my $dbh = Bugzilla->dbh;<br>
my @ret_list = eval {<br> my $userid = Bugzilla::User::login_to_id( $username );<br> if ( $userid > 0 ) {<br> $dbh->bz_start_transaction();<br> my $user = new Bugzilla::User($userid);<br>
Bugzilla->set_user($user);<br> my $bug = Bugzilla::Bug->check($bugid);<br> $bug->add_comment($comment, {isprivate => 0, work_time => 0, type => Bugzilla::Constants->CMT_NORMAL, extra_data => ""} );<br>
$bug->update();<br> $dbh->bz_commit_transaction();<br> return 0;<br> } else {<br> # This should never happen. Each user should have a<br> # corresponding userid in the database schema<br>
return 1, "Login '$username' could not be converted to an id in Bugzilla. Is username mapping setup correctly in daemon.conf ?\n" ;<br> }<br> }; # eval<br> if ($@) {<br>
my $err = $@;<br>
log_daemon_warn( undef, $err );<br> $dbh->bz_rollback_transaction() if $dbh->bz_in_transaction();<br> return 1, "Error while adding bug comment: $err";<br> }<br> else {<br>
return @ret_list;<br> }<br><br>We didn't have eval block here before - which resulted in aborting processing when check() fails and notifying scm user with quite general error message.<br><br>The case with change of status resolution is more interesting - you can see last section of additions (within eval block) in the attached patch.<br>
<br>I added that patch to simplify a bit the communication between scmbug and Bugzilla and reduce compatibility issues with current and future releases. What we had before was code initially developed against older versions of Bugzilla with multiple direct database calls, explicit validations.<br>
<br>So from my point of view - some kind of exception handling seems better in order to avoid bloating code and checking return codes on each step. However I see some drawbacks with the current die/eval/if($@) approach that I'm trying to hook in scmbug with that patch:<br>
- die/eval has some limitations - it's not easy /if possible at all/ to track original call stack (in order to see where did the error came from).<br> - Nor type of error could be easily distinguished (it's just plain text).<br>
+ Recent versions of Perl support object oriented exception handling mechanism which sounds better to me.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><br>
> I'm sure you folks must have a more user-friendly API than this. We must<br>
> be missing something.<br>
<br>
</div> Yeah, the WebService is the API.<br></blockquote><div>I can't find the link now but I've found some discussion where Kristis explained that WebService API was not powerful enough (maybe since the scmbug daemon should be able to impersonate as any user without requesting version control user to provide a password).<br>
As far as I see - Bugzilla cgi modules are using Perl API instead of WebService too.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
-Max<br>
<font color="#888888">--<br>
<a href="http://www.everythingsolved.com/" target="_blank">http://www.everythingsolved.com/</a><br>
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.<br>
-<br>
To view or change your list settings, click here:<br>
<<a href="http://bugzilla.org/cgi-bin/mj_wwwusr?user=nikolov.javor@gmail.com" target="_blank">http://bugzilla.org/cgi-bin/mj_wwwusr?user=nikolov.javor@gmail.com</a>><br>
</font></blockquote></div><br>