Class: moodle_exception  - X-Ref

Base Moodle Exception class

Although this class is defined here, you cannot throw a moodle_exception until
after moodlelib.php has been included (which will happen very soon).

Class: require_login_exception  - X-Ref

Course/activity access exception.

This exception is thrown from require_login()

Class: require_login_session_timeout_exception  - X-Ref

Session timeout exception.

This exception is thrown from require_login()

Class: webservice_parameter_exception  - X-Ref

Web service parameter exception class

Class: required_capability_exception  - X-Ref

Exceptions indicating user does not have permissions to do something
and the execution can not continue.

Class: coding_exception  - X-Ref

Exception indicating programming error, must be fixed by a programer. For example
a core API might throw this type of exception if a plugin calls it incorrectly.

Class: invalid_parameter_exception  - X-Ref

Exception indicating malformed parameter problem.
This exception is not supposed to be thrown when processing
user submitted data in forms. It is more suitable
for WS and other low level stuff.

Class: invalid_response_exception  - X-Ref

Exception indicating malformed response problem.
This exception is not supposed to be thrown when processing
user submitted data in forms. It is more suitable
for WS and other low level stuff.

Class: invalid_state_exception  - X-Ref

An exception that indicates something really weird happened. For example,
if you do switch ($context->contextlevel), and have one case for each
CONTEXT_... constant. You might throw an invalid_state_exception in the
default case, to just in case something really weird is going on, and
$context->contextlevel is invalid - rather than ignoring this possibility.

Class: invalid_dataroot_permissions  - X-Ref

An exception that indicates incorrect permissions in $CFG->dataroot

Class: file_serving_exception  - X-Ref

An exception that indicates that file can not be served

Class: bootstrap_renderer  - X-Ref

This class solves the problem of how to initialise $OUTPUT.

The problem is caused be two factors
<ol>
<li>On the one hand, we cannot be sure when output will start. In particular,
an error, which needs to be displayed, could be thrown at any time.</li>
<li>On the other hand, we cannot be sure when we will have all the information
necessary to correctly initialise $OUTPUT. $OUTPUT depends on the theme, which
(potentially) depends on the current course, course categories, and logged in user.
It also depends on whether the current page requires HTTPS.</li>
</ol>

So, it is hard to find a single natural place during Moodle script execution,
which we can guarantee is the right time to initialise $OUTPUT. Instead we
adopt the following strategy
<ol>
<li>We will initialise $OUTPUT the first time it is used.</li>
<li>If, after $OUTPUT has been initialised, the script tries to change something
that $OUTPUT depends on, we throw an exception making it clear that the script
did something wrong.
</ol>

The only problem with that is, how do we initialise $OUTPUT on first use if,
it is going to be used like $OUTPUT->somthing(...)? Well that is where this
class comes in. Initially, we set up $OUTPUT = new bootstrap_renderer(). Then,
when any method is called on that object, we initialise $OUTPUT, and pass the call on.

Note that this class is used before lib/outputlib.php has been loaded, so we
must be careful referring to classes/functions from there, they may not be
defined yet, and we must avoid fatal errors.