-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix apy modules tests - Re: #516 #522
base: master
Are you sure you want to change the base?
Conversation
A new function check_syntax_error was created to test if the appropriate syntax error is returned.
Maybe we could differentiate between |
@Androbin Sure, that's fine. Should I maybe create an enum or a dictionary? errors = {
'SYNTAX_ERROR': {
'LINE_ERROR': 1,
'CMD_ERROR': 2,
'TEXT_ERROR': 3
}
} Or with an enum: class SyntaxError(Enum):
LINE_ERROR = 1
CMD_ERROR = 2
TEXT_ERROR = 3 I could also maintain the current structure of adding constants at the top. However the dictionary seems more flexible, in my opinion. Could you please let me know which solution would be best? |
Nice writeup! I would argue for the |
I do have to say, this actually looks quite suspicious:
Actually, after closer inspection, I can't tell why these error names were picked originally. |
How about |
For example, a |
Created an enum for functions status. Renamed error variables to a more appropriate name.
@Androbin is this what you meant? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose there's more work to be done to integrate the other error types into the rest of the code? :P I only see SYNTAX_ERROR
and WEB_RESPONSE_ERROR
being used.
@wei2912 I can integrate the other error types, however this would envolve removing a lot of the thrown |
@wei2912 @Androbin Unfortunately this broke some of the tests and I wasn't able to fix them. In my opinion a good separate issue/ticket would be to think about a solid structure for error handling thats consistent across all modules, and temporarily fix the apy module's tests, so that we can verify if new changes break the module. Please let me know if I should push my attempt to replace |
IMO I don't think it's necessary to standardise the error reporting across all the modules. In nearly any other codebase I'd agree with the need for consistent error handling, but for a modular scripts system that Begiak has, I don't think it'd lead to much payoff. We could have each module handle exceptions as best as they can (since each module would have their own exceptions to deal with), and if they're unable to do so, the bot will attempt to catch the exception and report it unless it leads to an unrecoverable error. As for replacing This is related to #509. |
I'll be putting this into the commit message, let me know if it summarises the details well:
|
@wei2912 I meant replacing the use of I think a standerdise way of handling errors would be benefitial because as of right now, errors are all handled a bit differently in every module: we're using the |
@tomasff ah, I see. Please do try to replace `GrumbleError` completely and
let us know which tests break. I'll still accept your GCI submission for
fixing the tests, but will not merge until this is done.
How would the `Status` codes generalise to other modules? If you can
propose how to shift towards a standardised way, please feel free to create
an issue for it and I'll write up a few GCI tasks for that. Thanks for the
work so far!
…On Sun, 22 Dec 2019, 21:21 Tomás F., ***@***.***> wrote:
@wei2912 <https://github.com/wei2912> I meant replacing the use of
GrumbleError in handle_error and check_no_data. I tried doing this, but a
lot of tests related to the translate function broke and I wasn't able to
fix them. I will try again today. Should I create an issue for this?
I think a standerdise way of handling errors would be benefitial because
as of right now, errors are all handled a bit differently in every module:
we're using the Status codes in the apy module and GrumbleError's in
other modules.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#522?email_source=notifications&email_token=AAPZPF6OEQLITTRBHSLC7XDQZ5SULA5CNFSM4J6CN6LKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHPPV2A#issuecomment-568261352>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAPZPF2LT5S35DVDJ6TOCKTQZ5SULANCNFSM4J6CN6LA>
.
|
Also, no need to create a new issue for the tests failing when you replace
`GrumbleError` with `Status` in this module. Just keep us updated here on
the issues you face.
…On Mon, 23 Dec 2019, 06:24 Ng Wei En, ***@***.***> wrote:
@tomasff ah, I see. Please do try to replace `GrumbleError` completely and
let us know which tests break. I'll still accept your GCI submission for
fixing the tests, but will not merge until this is done.
How would the `Status` codes generalise to other modules? If you can
propose how to shift towards a standardised way, please feel free to create
an issue for it and I'll write up a few GCI tasks for that. Thanks for the
work so far!
On Sun, 22 Dec 2019, 21:21 Tomás F., ***@***.***> wrote:
> @wei2912 <https://github.com/wei2912> I meant replacing the use of
> GrumbleError in handle_error and check_no_data. I tried doing this, but
> a lot of tests related to the translate function broke and I wasn't able
> to fix them. I will try again today. Should I create an issue for this?
>
> I think a standerdise way of handling errors would be benefitial because
> as of right now, errors are all handled a bit differently in every module:
> we're using the Status codes in the apy module and GrumbleError's in
> other modules.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#522?email_source=notifications&email_token=AAPZPF6OEQLITTRBHSLC7XDQZ5SULA5CNFSM4J6CN6LKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHPPV2A#issuecomment-568261352>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAPZPF2LT5S35DVDJ6TOCKTQZ5SULANCNFSM4J6CN6LA>
> .
>
|
Sorry for the late reply.
I will try to look into this tomorrow.
…On Sun, 22 Dec 2019, 22:30 Ng Wei En, ***@***.***> wrote:
Also, no need to create a new issue for the tests failing when you replace
`GrumbleError` with `Status` in this module. Just keep us updated here on
the issues you face.
On Mon, 23 Dec 2019, 06:24 Ng Wei En, ***@***.***> wrote:
> @tomasff ah, I see. Please do try to replace `GrumbleError` completely
and
> let us know which tests break. I'll still accept your GCI submission for
> fixing the tests, but will not merge until this is done.
>
> How would the `Status` codes generalise to other modules? If you can
> propose how to shift towards a standardised way, please feel free to
create
> an issue for it and I'll write up a few GCI tasks for that. Thanks for
the
> work so far!
>
> On Sun, 22 Dec 2019, 21:21 Tomás F., ***@***.***> wrote:
>
>> @wei2912 <https://github.com/wei2912> I meant replacing the use of
>> GrumbleError in handle_error and check_no_data. I tried doing this, but
>> a lot of tests related to the translate function broke and I wasn't able
>> to fix them. I will try again today. Should I create an issue for this?
>>
>> I think a standerdise way of handling errors would be benefitial because
>> as of right now, errors are all handled a bit differently in every
module:
>> we're using the Status codes in the apy module and GrumbleError's in
>> other modules.
>>
>> —
>> You are receiving this because you were mentioned.
>> Reply to this email directly, view it on GitHub
>> <
#522?email_source=notifications&email_token=AAPZPF6OEQLITTRBHSLC7XDQZ5SULA5CNFSM4J6CN6LKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHPPV2A#issuecomment-568261352
>,
>> or unsubscribe
>> <
https://github.com/notifications/unsubscribe-auth/AAPZPF2LT5S35DVDJ6TOCKTQZ5SULANCNFSM4J6CN6LA
>
>> .
>>
>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#522?email_source=notifications&email_token=ADTBQKBBL47NIYSP6IZKBGDQZ7TARA5CNFSM4J6CN6LKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHP3FII#issuecomment-568308385>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADTBQKGME6OWX4XJNA5W2FTQZ7TARANCNFSM4J6CN6LA>
.
|
@tomasff have there been any updates ever since your last comment? :P |
Hi,
Not yet. I've been busy with Christmas. Hopefully I'll have it ready for
tomorrow.
So sorry for the delay
…On Sat, 28 Dec 2019 at 15:58, Ng Wei En ***@***.***> wrote:
@tomasff <https://github.com/tomasff> have there been any updates ever
since your last comment? :P
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#522?email_source=notifications&email_token=ADTBQKGSRQMNH5ZTWUKBXEDQ25ZSRA5CNFSM4J6CN6LKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHYMRBQ#issuecomment-569428102>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADTBQKC2OEWOSG2WG3LRIPTQ25ZSRANCNFSM4J6CN6LA>
.
|
@tomasff Hi, I just realised this PR hasn't been merged yet... how's the progress on this? :P |
@wei2912 Sorry for the delay, I've been busy these past weeks. I'll try to finish it by next week. |
No worries, please take your time! It's not an urgent matter.
…On Fri, Feb 21, 2020 at 11:24 PM Tomás F. ***@***.***> wrote:
@wei2912 <https://github.com/wei2912> Sorry for the delay, I've been busy
these past weeks. I'll try to finish it by next week.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#522?email_source=notifications&email_token=AAPZPFYE3M5MDEVHLRP6DYLRD7W35A5CNFSM4J6CN6LKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMTBZHI#issuecomment-589700253>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAPZPF7GO66TAPJOEZQ3TH3RD7W35ANCNFSM4J6CN6LA>
.
|
This pull request attempts to fix issue #516.
Two changes were made:
SYNTAX_ERROR
is returned if a syntax error occurred. This change was made so that several functions in this module can be tested again. (Related to changes in Display error messages due to wrong usage to users instead of admins #504)check_syntax_error
was created to test if a function returns the appropriateSYNTAX_ERROR
code.Althought this is not a very elegant solution it should allow us to test for any problems in this module when changes occur, while a more robust solution with maybe more specific exceptions isn't implemented.