Instead of raising a whole variety of exceptions, they are now wrapped
into ExtensionError derived classes.
* ExtensionAlreadyLoaded
* Raised when an extension is already loaded in Bot.load_extension
* ExtensionNotLoaded
* Raised when an extension is not loaded, e.g. Bot.unload_extension
* NoEntryPointError
* Raised when an extension does not have a `setup` function.
* ExtensionFailed
* Raised when an extension's `setup` function fails.
* ExtensionNotFound
* Raised when an extension's module import fails.
This causes them to be raised from a new exception named
ArgumentParsingError with 3 children for ease with i18n. This is
technically a breaking change since it no longer derives from
BadArgument, though catching UserInputError will prevent this change
from affecting the user.
This assumes that a Converter class raising non-CommandError
is a programmer error. Makes this type of error easier to
disambiguate from a generic BadArgument.
This is a breaking change. The original purpose of no_pm has been
mainly a legacy aspect. They came from a time before checks were a
generalised concept and were never removed. A check is the proper way
to do its behaviour.
The way the command cooldown works is using a windowed way of doing it.
That is, if we have a cooldown of 2 commands every 30 seconds then if we
do a single command, we have 30 seconds to do the second command or else
we will get rate limited. This more or less matches the common
expectations on how cooldowns should be.
These cooldowns can be bucketed up to a single dimension of depth for
a per-user, per-guild, or per-channel basis. Of course, a global bucket
is also provided. These cannot be mixed, e.g. no per-channel per-user
cooldowns.
When a command cooldown is triggered, the error handlers will receive a
an exception of type CommandOnCooldown with proper information regarding
the cooldown such as retry_after and the bucket information itself.
This is for exceptions that are inherently based on user errors and not
permission based. e.g. passing incorrect number of arguments, too many
arguments, or an invalid argument. CommandNotFound is not classified
under this since it isn't inherently a user input error in all cases.
Some invalid commands can simply be due to an odd bot prefix. It would
also diminish the usefulness of the new parent class if CommandNotFound
was included.
This allows you to strictly require a number of arguments. The default
behaviour in this case is still `True`, since it would be a breaking
change otherwise and is a sane default. However if someone would want
to set this to `False`, they would receive an exception of type
`TooManyArguments` if too many arguments are passed to a command.
Hopefully this removes the uses of `ctx.message.content == 'stuff'`
inside commands.
This change should make it a bit more intuitive to get the original
exception without having the gotcha of checking ``isinstance`` inside
the error handler.
