Skip to content
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

Implemented the mentor's backend. #1492

Open
wants to merge 20 commits into
base: 1604-implement-ai-mentor
Choose a base branch
from

Conversation

OpenJudgeSystem.sln Outdated Show resolved Hide resolved

if (userMentor.RequestsMade > (userMentor.QuotaLimit ?? GetNumericValue(settings, nameof(MentorQuotaLimit))))
{
throw new BusinessServiceException($"You have reached your message limit, please try again after {GetTimeUntilNextMessage(userMentor.QuotaResetTime)}.");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How is this displayed? I don't like throwing exception for expected (and frequent) behavior. We should handle this case by returning a message in the response model.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it necessary to add another property to the response model just for this case? Aren't exceptions (BusinessServiceExceptions), supposed to handle cases where the user has made a mistake / a user specific error has occurred and it has to be displayed?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't consider this a user mistake. The user is not responsible to track the reset time. BusinessServiceException indicates that some violation of the business logic has happened - and this is not a violation, but normal and totally expected behavior.
Apart from this, I don't like the BusinessServiceException either. Better alternative would be to return a result with the error in the response, than throwing.. but this is another topic.

@deyordanov deyordanov added the WIP Work in progress label Nov 22, 2024
@deyordanov deyordanov removed the WIP Work in progress label Nov 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants