Refactor - Error handling, performance profiling

[Apogate]

After the completion of Regist's conversion, I think it's time for some proper error handling and some basic performance profiling. Basically, making debug mode more potent than just allowing PHP error reporting.

---

Error To do:

• [ ] Rewrite vague strings, perhaps all error messages entirely.
  • We're still using futallaby-era error strings. "Error:Abnormal reply" is fine to keep things vague to the everyday user, but when debug mode is enabled and "Abnormal reply" has no documentation anywhere other than It is a mystery! in the strings file, it's not helpful at all.
  • [ ] Separate error strings from user strings via prefix. For example, S_UNJUST and S_NAME are both defined strings, but might be confusing when reading the code. Errors with a prefix of E_ or something similar.
• [ ] Error class for more powerful/flexible handling options.
• [ ] Errors redirect from wherever they are generated. IE, failing captcha in a thread would bounce you back to the thread instead of the index. Extremely desirable in certain situations.
• [ ] Functions return status reports for certain actions, ie usrdel returns success if called via ajax etc

Profiling To Do:

• [ ] Basic runtime execution tracking, microtime() start to finish or w/e
• [ ] Perhaps have saguaro generate logs for SQL queries, transactions or php actions blah blah blah
• [ ] //?

[Apogate]

It would actually make sense to convert the language/string files to variable-array. Cuts down on "costly" defines and has the added benefit of being overwriteable.

[RePod]

The problem with switching off constants (which itself is just a proxy) is that they'd be inaccessible without using global to include them in the local scope every time we need them.

Also due to your new E_ strings, they're currently not defined by the proxy. However, I do not recommend using E_ as PHP uses that prefix for its own errors.

Possible solutions:

• Somehow make it (the array) a superglobal but it's not that simple.
• PHP 5.6+ supports arrays as constants.
  • However they're finicky.

---

My previous class-based solution for a situation like this was for the config:

<?php
$config = array();
$config['aye'] = [ 'lmao' => 'xd' ];
$config['webm'] = [
    'allow' => false,
    'maxduration' => 30,
    'audio' => true
];

var_dump($config); //Dumps current config.

class SaguaroConfig {
    private $config = array();
    function init($config) {
        if ($config && empty($this->config)) {
            $this->config = $config; //Store once.
        } else {
            return "Some problem with config init.";
        }
    }
    function get($key = null) {
        return ($key) ? $this->config[$key] : $this->config;
    }
}

$backup = new SaguaroConfig; $backup->init($config);
unset($config); var_dump($config); //null
var_dump($backup->get()); //Dumps copied config contents.
?>

The problem though is unlike constants it's really difficult to group them and automate them like the current config file does so well (aside from the fact they cannot be changed later in execution).

Also it would effectively require two classes: Languages and Error. Languages to contain the strings and Error which fetches them from the Languages class. The benefit though is we can modify both freely to produce the results we want across the software (like having Language replace all "aye"s with "lmao").

A disadvantage to this is, given my example class, it's read-only. However this shouldn't be an issue because if we really wanted to change it we could (hopefully securely) read it out and use a modified version of what we want.

Another disadvantage to this, unlike classes, is it's not true read-only. At least in its current form. There are two ways to combat it being reinitialized (by literally creating a new instance):

• Do not make it accessible via variable.
  • Like you've seen before, I've accessed classes via ClassName::function() which is a direct call to the class itself.
  • Unfortunately we can't use things like $this and store info within the class long-term meaning we'd need to hit up the config each time.
• Protect it some other way.

[RePod]

Also I think you're abusing milestones.

I updated my previous comment with my last proposed solution (albeit for config, it still works).