Bad Request bomb out or poor prgamming style?

[susanodd]

In the review, this came up:

... to handle the case of when a gloss has the "old style" "senses example sentences" is to NOT allow the gloss senses to be updated via the API. Attempts to do so will give error "not allowed" feedback as such and not update the senses.

Just noticed this part, which I didn't respond to yet: indeed, if updating senses is not possible because of relations to example sentences, return an HTTP 422. Could you please add that check before you merge to merge? Thanks!

Once upon a time, it was considered poor programming pratice to use "break" or "goto" inside of a for loop.
Today, we commonly use try-except and just let things fail and catch them.

Lots of the API implementation has made an effort to provide user-friendly "error messages" as feedback instead of just giving status=400. But if the user does not notice that error messages have been returned and that the operation has, in fact, failed, this is a problem.

What to do with an error on the input of the API?

What to do with control flow for Bad Request?

Example:

        if field in ['Senses', 'senses']:
            if ExampleSentence.objects.filter(senses__glosses=gloss).exists():
                errors[field] = gettext('API UPDATE NOT AVAILABLE: The gloss has senses with example sentences.')
            continue

Or should we immediately thrown an error with BadRequest ?

[Woseseltops]

After discussing with @susanodd , we came to the conclusion BadRequest is probably what users prefer. So you get all or nothing. Importantly, it should also report why and give advice on how to fix.