A suggestion to the first option. It means no bug can be without a type and after assessment can be reassigned. (I like your not reproduceable bugs point too)
This was an informative video. But I suggest that "Out of bounds (boundary condition)" BUGS should not be defined as user creating such scenario but instead as not implementing "handling of such boundary exceptions".
Please help. I have been receiving error messages apon opening certain programs with the message "assert failure mscorlib recursive resource lookup bug" is there any fix for this? I have been troubleshooting all week with no success and there is next to no fix online. If you could help me out you would be a real life saver
BUG, or not to BE BUGGED…. Unfortunately once you LOOSE your “code or access” you MIGHT PAY the ultimate LOSS of LIFE, as in… frustrating messages cause frustrating acts of violence, too! Deadly is NEVER A GOOD thing… EVERYONE! Especially in our SCHOOLS!!!
Seems foolish to create a bug category of Functional Errors just because the nature of the error hasn't been determined yet. Ultimately every sort of error is going to be a Functional Error even if it can remain undetected for a long time. By the way, what about *Heisenbugs* ? These are bugs that occur occasionally in system operation but are impossible to detect during a determined attempt to reproduce and isolate them. (The analogy is with _Heisenberg's Uncertainty Principle_ which says that the probabliity of locating an electron's position is inversely proportional to the probability of measuring its momentum.) Often these bugs are a result of subtle differences in system behavior between run- and debug- mode settings.
