Raise exceptions for `{"result": "error"}` in `zulip` apis.

[LoopThrough-i-j]

Currently, zulip API doesn't handle {"result": "error"} and sends send back whatever comes from the server. We would want to handle these errors by raising exceptions in the API layer whenever there is a {"result": "error"}.

Reference

[alexzw7]

@zulipbot claim

[zulipbot]

Hello @alexzw7!

Thanks for your interest in Zulip! You have attempted to claim an issue without the labels "help wanted", "good first issue". Since you're a new contributor, you can only claim and submit pull requests for issues with the help wanted or good first issue labels.

If this is your first time here, we recommend reading our guide for new contributors before getting started.

[alexzw7]

@zulipbot add "good first issue"

[alexzw7]

@zulipbot claim

[zulipbot]

Welcome to Zulip, @alexzw7! We just sent you an invite to collaborate on this repository at https://github.com/zulip/python-zulip-api/invitations. Please accept this invite in order to claim this issue and begin a fun, rewarding experience contributing to Zulip!

Here's some tips to get you off to a good start:

• Join me on the Zulip developers' server, to get help, chat about this issue, and meet the other developers.
• Unwatch this repository, so that you don't get 100 emails a day.

As you work on this issue, you'll also want to refer to the Zulip code contribution guide, as well as the rest of the developer documentation on that site.

See you on the other side (that is, the pull request side)!

[LoopThrough-i-j]

@zulipbot remove "good first issue"

[PIG208]

A brief note for this one here: we might need to add a common exception class called BotError and specify a set of sub errors like AccessDenied etc. (we need to discuss the naming). I think we can have a protocol that can be shared with embedded bots as well. An anticipated result of this might be that the user will no longer need to examine the returned dictionary from the API and instead they can simply do error handling with try-except statements.

[timabbott]

Yeah, I think that's a good idea.

[neiljp]

Is it the intent of this issue to evolve all of the zulip python API to have different return values and raise exceptions instead? While ZT can adapt to this per zulip library release, this seems like a big API transition to make for all dependent packages/scripts.

If this is an evolution of zulip, then BotError seems misnamed, unless this issue is specific to the bots library instead?

[timabbott]

I think so. One theory is that we could provide a legacy_exception_handling flag to the Client() constructor that resulted in it using the old error-handling method of converting errors for backwards-compatibility.