Closed
Bug 166023
Opened 22 years ago
Closed 22 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•22 years ago
|
Assignee | ||
Comment 1•22 years ago
|
||
I could not duplicate the problem that complaining users have
Comment 2•22 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•22 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•22 years ago
|
||
gerv: Yes, but: $template->process(...)|| ThrowTemplateError(...) will crash if $template is undef.
Comment 5•22 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•22 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: 22 years ago
Resolution: --- → FIXED
Updated•22 years ago
|
Whiteboard: [want for 2.16.1]
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18
Comment 7•22 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•22 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: 22 years ago → 22 years ago
Resolution: --- → FIXED
Updated•22 years ago
|
Whiteboard: [want for 2.16.1] → [fixed for 2.16.1]
Updated•12 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
•