CraftSpider
CommandException get's raised all the way to tests
When discord is normally running you can throw a CommandException (such as in a convertor) which will cause the event on_command_error to run. This happens, but normally the exception is killed along the way. However, it's making it all the way back to my test (which I don't think is the proper behavior). I've tried to diagnose but have been unable to find out why it's not being killed. It looks like it should die at bot.py!BotBase.invoke (line 893) but somehow it's not behaving the same in your test suite. Any help would be appreciated.
erm might be runner line 271, seems like that might need a case for when it's a CommandError, but I'm not positive.
so threw in some code to handle that but now I'm getting really weird behavior. my on_command_error code awaits a task using Messageable.send(). I can step over the await call of the task, and sometimes hit my breakpoint in Messaeable.send and sometimes not. No real idea why it lands sometimes and not others. Either way, if it does happen, my message get's put into the sent queue, but by the time it makes it back to my test the sent_queue has been cleared? which I can't figure out how or when that is happening either.
oh and it can execute like down the road too, I think think somehow the way you are using async in the test framework is causing problems with the way discord is allowed to operate.... Or I'm just horribly abusing async. like I said I'm scheduling a task to send items FROM the on_command_error. That seems to be causing serious problems.
ok I switched and just await the coro instead of scheduling a task, and voila it seems to work. Still not sure if this is a Me problem or a test-framework problem, or maybe something that just needs to be understood. But in the concept of my bot I was ok with scheduling the send as a task... (I'm basically sending back a variety of messages as they become available). However it completely breaks the framework. I wonder if there needs to be a separate event loop that we ensure is empty for the bot, since it seems currently as though we are using the same loop. I'm very new to async, so I could just be horribly wrong.
looping back around though, for things to work I did have to get rid of your raise(err[1]) in runner.py when it's a CommandError. I think this is the intended way to do things, as usual I can start submitting some pull requests if you want.
The error being re-raised on test is intentional, an error propagating out of the command is considered a thing that should be explicitly marked as with pytest.raises
interesting, I assumed because they squash the error you would as well. that works perfectly well however, thank you.
Do you have any thoughts on the inability to use tasks with the same loop?