You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Talk about that analyzers should rarely intentionally thow an error. Rather, a reason for an error likely suggests that a new error topic should be created
my gut is that they should generally not throw. For ex.. if we had:
A topic for if Npcs.SomeField was corrupt
A topic if Npcs.SomeField aligned with something else
And there was a record /w it corrupt... we'd want to just show the topic #1
Topic #2 is almost N/A, as it can't even get there. If it threw, we'd have to almost treat that as something to show about #2 to the user, as we couldn't distinguish if that's expected or an actual problem. You could imagine something fundamental being wrong with a record that we have an analyzer to detect, but its report is flooded and hidden by all the "downstream" analyzers that are throwing up and spamming the system
obviously unexpected throws will happen? But those should be shown to the user for them to look at and/or report for improvement?
for 2)... i'd say it should maybe just catch and return without reporting a topic if 1) happened to it?
Or, if it's a single analyzer (like footsteps), it would report 1, and then know to not check 2 (and therefore not throw)
The text was updated successfully, but these errors were encountered:
Talk about that analyzers should rarely intentionally thow an error. Rather, a reason for an error likely suggests that a new error topic should be created
my gut is that they should generally not throw. For ex.. if we had:
And there was a record /w it corrupt... we'd want to just show the topic #1
Topic #2 is almost N/A, as it can't even get there. If it threw, we'd have to almost treat that as something to show about #2 to the user, as we couldn't distinguish if that's expected or an actual problem. You could imagine something fundamental being wrong with a record that we have an analyzer to detect, but its report is flooded and hidden by all the "downstream" analyzers that are throwing up and spamming the system
obviously unexpected throws will happen? But those should be shown to the user for them to look at and/or report for improvement?
for 2)... i'd say it should maybe just catch and return without reporting a topic if 1) happened to it?
Or, if it's a single analyzer (like footsteps), it would report 1, and then know to not check 2 (and therefore not throw)
The text was updated successfully, but these errors were encountered: