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.
Previously, calls to add_line in add_command_formatting of default help
commands would fail if the command's help message would overflow the
current page. This would also result in silent failure as the
RuntimeError raised from add_line is never caught.
This patch adds behavior that adds lines individually should it raise,
which guarantees safe pagination as long as every line is smaller than
the maximum page size, which is highly unlikely.
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 bug was kind of a long one to figure out, as per #1918 documents
the issue had to do with subcommands but the actual adventure in
finding this one was a long one.
The first problem was that Command.cog was for some reason None, which
indicated that a copy was happening somewhere along the way. After some
fiddling I discovered that due to the copies of `Cog.__cog_commands__`
the groups pointed to out-dated versions that got overriden by the new
copies.
The first attempt at fixing this was straightforward -- just remove the
subcommand from the parent and replace it with the newer reference that
we just received. However, this ended up not working due to a strange
mystery where the subcommand being invoked was neither the original
copy nor the new copy residing in `Cog.__cog_commands__`.
Some more investigation later pointed out to me that a copy occurs
during the `Group.copy` stage which calls `Command.copy` for all its
subcommands. After spotting this out I had realised where the
discrepancy comes from. As it turns out, the subcommand copy that was
being invoked was actually a stale one created from `Group.copy`.
The question remained, how come that one was being called? The problem
stemmed from the fact that when the subcommand was copied, the parent
reference pointed to the old parent. Since the old parent was the one
that was getting the new reference, it went practically untouched. This
is because the calling code fetches the child from the parent and the
old parent is nowhere in the call chain.
To fix this issue we needed to update the parent reference, and in
order to do that a temporary lookup table is required pointing to the
latest copies that we have made.
Thus ends a 3.5 hour bug hunting adventure.
Rapptz
Joshua BandRapptz
NCPlayzandRapptz
sliceandDanny
Kaeptm BlaubaerandDanny
Harmon
SkywebandRapptz
Myst(MysterialPy)andRapptz
cod
Benjamin MintzandRapptz