The short answer from me is: You shouldn't ever carry on with a buggy game state. Anything you do carry on with needs to be considered "acceptable" at minimum.

  While @Theraot was on point with the discussion of environments, in my opinion it's actually a little bit more simple: Instead of considering what environment you're running, instead consider this: Who is seeing the error?

• A Developer: Fail fast, and fail hard. Any unfixed bugs that make it past the developer will only become a bigger headache for people who know nothing about the code. I won't touch on runtime assertions here, but in my opinion it fails under the "fail-fast" mentality (Per @DMGregory: If the error can't happen, you never need to worry about it!).
• A Tester: Similar to developers, but provide more information than typically necessary, to save time in hunting down the details of a bug once reported. This would be akin to printing stack information, variable inputs, etc.
• A User: Again, fail fast. In this case, however, the end-user is very unlikely to be able to make use of the information that would be presented to a tester or developer. They need a new class of feedback.

In terms of responding to a user about crashing feedback, let's go off into a real world example, Minecraft's older error reporting system: Hopper.

On a game crash, a user would be presented with a plethora of information that was seemingly useless to anyone code-illiterate (read: many young children playing the game):

To alliviate this, Mojang added Hopper, which would receive a report from the client of the unique type of crash (e.g. you could hash the stack trace). The service can then have a landing page for those errors, which would provide more specific, user-level feedback about the crash, and how to fix it.

The main point I'm trying to drive home here is that lots of information can be good and helpful. However, in a production environment, sometimes more information can actually just mislead and confuse people, versus a simpler explanation from someone who understands the context of the issue. This also allows you to explain real-world crashes that aren't fixable by developers (e.g. not having graphics drivers installed), and provide remedies for those issues to your end-users.

You should not accept a buggy game state, as simply letting a bug continue onward in your game can leave as bad of an impression on users as your game crashing. But game crashes are much more obvious and likely to be fixed than silent bugs, motivating your developers to not push a buggy/crashing build to begin with.

The short answer from me is: You shouldn't ever carry on with a buggy game state. Anything you do carry on with needs to be considered "acceptable" at minimum. While @Theraot was on point with the discussion of environments, in my opinion it's a little bit more simple. Instead of what environment you're running, consider this: 

Who is seeing the error?

• A Developer: Fail fast, and fail hard. Any unfixed bugs that make it past the developer will only become a bigger headache for people who know nothing about the code. I won't touch on runtime assertions here, but in my opinion it fails under the "fail-fast" mentality (Per @DMGregory: If the error can't happen, you never need to worry about it!).
• A Tester: Similar to developers, but provide more information than typically necessary, to save time in hunting down the details of a bug once reported. This would be akin to printing stack information, variable inputs, etc.
• A User: Again, fail fast. In this case, however, the end-user is very unlikely to be able to make use of the information that would be presented to a tester or developer. They need a new class of feedback.

In terms of responding to a user about crashing feedback, let's go off into a real world example, Minecraft's older error reporting system: Hopper.

On a game crash, a user would be presented with a plethora of information that was seemingly useless to anyone code-illiterate (read: many young children playing the game):

To alliviate this, Mojang added Hopper, which would receive a report from the client of the unique type of crash (e.g. you could hash the stack trace). The service can then have a landing page for those errors, which would provide more specific, user-level feedback about the crash, and how to fix it.

The main point I'm trying to drive home here is that lots of information can be good and helpful. However, in a production environment, sometimes more information can actually just mislead and confuse people, versus a simpler explanation from someone who understands the context of the issue. This also allows you to explain real-world crashes that aren't fixable by developers (e.g. not having graphics drivers installed), and provide remedies for those issues to your end-users.

You should not accept a buggy game state, as simply letting a bug continue onward in your game can leave as bad of an impression on users as your game crashing. But game crashes are much more obvious and likely to be fixed than silent bugs, motivating your developers to not push a buggy/crashing build to begin with.