I think the best way to approach this is to determine what you actually want to consider a Bug first.
A lot of developers will not consider something that isn't working as intended that they are currently working on as not a bug, because it is honestly not a bug. If you are currently working on something and it still has defects then the specific bug isn't actually complete so there isn't an actual defect. The inverse applies to completed work, if you have determined that something is complete and ready for testing/release/production and you later find a defect in the code or use then you definitely have a bug.
My company uses the following methodology to determine when a bug should be corrected:
If the bug is critical then it is added to the current sprint related to that product, at the appropriate priority. Typically we plan in approximately 10% extra time to allow for this into a sprint, as well as having the extra things that we don't actually plan on completing but if we have no bugs or something was completed faster than we expected we can then complete.
If a bug isn't critical then we simply add it to the backlog and normally complete it in the next sprint.
why this is the ideal flow there is some obvious leak to it, and sometimes things that aren't 'critical' from a programming perspective may need to be completed immediately if management decides that it needs to be completed earlier than we think it should be completed.
In an aside I think that the best thing to do is to pick a structure and then stick with it. Some of the biggest losses to productivity start occurring when you start doing things without structure. Once you start degrading your structure it is very easy for it to go all downhill.
That may have overly answered your question, but those are just my thoughts on how these things should be handled.