« BBCode trimming issues?
Possible incorrect behaviour in fatal error handling?
SMF bug 4954 (poll options can get mixed up when > 127 optio… »

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Possible incorrect behaviour in fatal error handling?
« on February 29th, 2012, 02:57 AM »
OK, so I'm fixing up the calendar at last, and there's the grisly assortment of mismatches of variables and things out of scope where they were before in the original code and I forgot to preserve it.

But, interestingly, I got this to happen.

The top template, as you might recognise, is the fatal error template. The theory is that it should normally override everything and anything. But it's called with a simple wetem::load, and as it happens in this case, another wetem::load has already been issued before we get to the actual fatal_lang_error call.

I'm inclined to think that the fatal error should override and remove anything in the default layer rather than the current prepending behaviour.

Thoughts (Nao especially)?

📎 calendar_impossible_fatal_error.png - 29.12 kB, 640x458, viewed 209 times.

When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

live627

  • Should five per cent appear too small / Be thankful I don't take it all / 'Cause I'm the taxman, yeah I'm the taxman
  • Posts: 1,670
A confident man keeps quiet.whereas a frightened man keeps talking, hiding his fear.

Nao

  • Dadman with a boy
  • Posts: 16,079

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Possible incorrect behaviour in fatal error handling?
« Reply #3, on February 29th, 2012, 08:57 AM »
If stuff is written properly, no, because it's just a template being executed and other execution is appropriately suspended. However, if that template relies on content being set up that it would otherwise expect and now isn't, then it'll dump other errors into the log.

Now, of course, in an ideal world we wouldn't normally call wetem::load before having validated everything so that we wouldn't need to worry about it but there are times it's going to happen, with the above as a consequence.

Nao

  • Dadman with a boy
  • Posts: 16,079
Re: Possible incorrect behaviour in fatal error handling?
« Reply #4, on February 29th, 2012, 09:47 AM »
The error system has its errors itself.

For instance a template error (index?) will sometimes regenerate the full page inside of itself. I always smile when it happens. No biggie though. I don't know about the problem you mention though.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Possible incorrect behaviour in fatal error handling?
« Reply #5, on February 29th, 2012, 10:12 AM »
Quote
For instance a template error (index?) will sometimes regenerate the full page inside of itself. I always smile when it happens. No biggie though
I'd noticed that, heh.

The main fix, primarily, though would be to simply have the fatal error handler dropping everything inside default and only using its own template. Would likely fix the other mentioned issue too.

Nao

  • Dadman with a boy
  • Posts: 16,079

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278

Nao

  • Dadman with a boy
  • Posts: 16,079

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278

Nao

  • Dadman with a boy
  • Posts: 16,079

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Possible incorrect behaviour in fatal error handling?
« Reply #11, on March 10th, 2012, 01:23 PM »
Hmm, I still get the nesting sometimes with fatal errors and not with others. It tends to be database errors that trigger the behaviour, whereas most manual invocations of fatal_lang_error don't cause it. I still think we need to have the error handler replace <default>

Mind you in the event of a fatal error (assuming it isn't a template error), we probably should consider dropping as many templates as possible because imagine the situation: a portal early in processing adds its templates to the skeleton but never populates them until later, all the added templates could fail too, though I'd probably suggest in that scenario there's a fundamental bug in the portal for not populating its data when adding template blocks/layers.

Nao

  • Dadman with a boy
  • Posts: 16,079

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278

Nao

  • Dadman with a boy
  • Posts: 16,079
« BBCode trimming issues?
SMF bug 4954 (poll options can get mixed up when > 127 optio… »