Closed
Bug 166023
Opened 23 years ago
Closed 23 years ago
On failure in template->new, a template is used to display error
Categories
(Bugzilla :: Installation & Upgrading, defect)
Tracking
()
RESOLVED
FIXED
Bugzilla 2.18
People
(Reporter: bugreport, Assigned: bugreport)
References
Details
(Whiteboard: [fixed for 2.16.1])
Attachments
(1 file)
603 bytes,
patch
|
bbaetz
:
review+
bbaetz
:
review+
|
Details | Diff | Splinter Review |
Bugs such as bug 165133 show failures in checksetup that derive from the fact
that globals.pl uses DisplayError() to show errors in Template->new
Since DisplayError() will never work if Template->new fails, this should be a
die() instead.
Assignee | ||
Updated•23 years ago
|
Assignee | ||
Comment 1•23 years ago
|
||
I could not duplicate the problem that complaining users have
Comment 2•23 years ago
|
||
Comment on attachment 97446 [details] [diff] [review]
Replace DisplayError with die
r=bbaetz x2
Technically, DisplayError will display text if it can't handle the template,
but that needs a bit of work to avoid trying to call the method on an undefined
object.
That work will fall out of modulisation, anyway, so we shouldn't care about it
now.
Attachment #97446 -
Flags: review+
Comment 3•23 years ago
|
||
If a template fails, you should be using ThrowTemplateError($template->error).
This tries to report the error using another template (fine if e.g. the first
template is missing) and then falls back on "print" statements.
There is documentation in the code near the *Error functions on which ones to
use when.
bug 165133 is caused by the fact that we don't define the *Error functions early
enough. That needs fixing first.
Gerv
Comment 4•23 years ago
|
||
gerv: Yes, but:
$template->process(...)|| ThrowTemplateError(...)
will crash if $template is undef.
Comment 5•23 years ago
|
||
> $template->process(...)|| ThrowTemplateError(...)
>
> will crash if $template is undef.
Indeed. OK, I get it now. die seems fine in this one case. Sorry :-)
Gerv
Assignee | ||
Comment 6•23 years ago
|
||
Checking in globals.pl;
/cvsroot/mozilla/webtools/bugzilla/globals.pl,v <-- globals.pl
new revision: 1.199; previous revision: 1.198
done
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Updated•23 years ago
|
Whiteboard: [want for 2.16.1]
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18
Comment 7•23 years ago
|
||
I'm in IRC odd hours now, so I'll just ask in the bug: what's the holdup on
checking this into the 2.16 branch?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 8•23 years ago
|
||
Didn't realize it was waiting for me...
Checked into 2.16 Branch:
Checking in globals.pl;
/cvsroot/mozilla/webtools/bugzilla/globals.pl,v <-- globals.pl
new revision: 1.169.2.11; previous revision: 1.169.2.10
done
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Updated•23 years ago
|
Whiteboard: [want for 2.16.1] → [fixed for 2.16.1]
Updated•13 years ago
|
QA Contact: matty_is_a_geek → default-qa
You need to log in
before you can comment on or make changes to this bug.
Description
•