Let's assume that I've found some behaviour in a language/library/client etc. that is definitively, provably, incorrect; for instance a function called 5 times executes 6 times in one context in one client and 5 times everywhere else (don't ask). I realise this sounds arrogant and that the typical answer is that it's a problem with the code rather than anything else but let's assume, for the sake of argument, that I'm correct; I've done my research extremely thoroughly and I'm certain.

I would really like to whether or not this behaviour is expected, because it's entirely possible me and my colleagues are completely unaware of some "feature" that's causing what appears, at first glance, to be a bug. However, I don't ask the question because I'm fairly certain it's a bug.

If it is a bug the question becomes a statement of my investigation followed by the "Is this a bug or is it some feature I'm unaware of?". The answer would either be "It's a bug." or a description of the problem. I might be able to provide the "bug" answer at the same time if I can find a verified bug report.

This doesn't appear to be the sort of question/answer that would fit Stack Overflow particularly well. Do you agree or disagree? Why?

This question (the meta one) has, I think, two answers. I work mostly with two technologies, Python and Oracle. Oracle is so closed source that you can lose your support licence if you post details of a bug report in the wider world (though some Oracle DBAs have still ripped it to pieces and can answer what seem like impossible questions - nothing can be truly closed). Python is so open source that you can view the original source code.

Would your answer to this question be different if the language/library/client etc. in question was open source or closed?

Apologies for the gratuitous bolding but I think the question marks are in the correct places here and I couldn't find a less ostentatious way of making them stand out.

  • Just make sure that it takes the form of a legitimate question and answer, rather than looking like a blog post Commented Feb 19, 2014 at 22:57

5 Answers 5


Rather than asking, "Is this a bug or a feature?" simply ask, "Why does this produce X? I expected it to produce Y instead." The answer to that question may be "it's a bug", or it could be an explanation of how you're improperly observing the results, configuring your application, or whatever. In any case, it's much more likely to produce a quality answer. When you ask "why", you can get a quality, detailed explanation of what is wrong. When you ask, "is it A or B" it's just too tempting to answer with nothing more than "A" or "B", which just isn't as helpful.

  • You're completely correct for open source projects (I'm still learning how to ask a decent question) - and I do like to ask why. But, does your answer hold true for closed-source projects where you're a lot less likely to get a detailed explanation because no one knows that one exists and if they do know they're contractually bound to not tell you? Commented Feb 19, 2014 at 21:36
  • 4
    @benisuǝqbackwards If nobody knows the answer to the question then nobody knows the answer to the question. You can still ask it. That said, I don't see how someone could answer your version of the question and not mine. If they know it's a bug, they can explain that it's a bug, link to whatever sources indicating that, etc. If you did something wrong, then can explain how to fix it. This is done all of the time without the source code of the underlying application. Partly you rely on documentation and specs. if the specs say it should produce X, and it produces Y, then you have a bug.
    – Servy
    Commented Feb 19, 2014 at 21:39

Ask under the assumption it isn't a bug. Worst case scenario, it is a bug, but you've still confirmed this, where an answerer has hopefully given a quality answer explaining their findings. Best case scenario, it isn't a bug, but a fault with your implementation, and the answerer has given you a solution.

Another answer could confirm it is a bug, but provide a workaround, again useful to you and the community. So yes, absolutely ask, but try to avoid jumping to conclusions in your question.


That depends on several factors. Do you have something useful to say, beyond the existence of the bug?

  • Is the bug difficult to diagnose? If so, post a question with the symptoms and an answer that pinpoints where the bug is.
  • Do you have a non-obvious workaround? If so, post a question describing the situation in which the bug occcurs, and an answer showing this workaround.

If the Q&A pair is just “if the user clicks 5 times then the event is triggered 6 times” → “it's a bug”, it doesn't help to have it around. But if you have more information to share that could help other people who encounter the same bug, please do.

Keep in mind that SO is not a place to report bugs — do that with the maintainer of the application of library. If there is a public bug tracker, please link to the bug. If you know what versions are affected by the bug, please mention that.

  • I'm not attempting to report bugs, but I'd like to know if the behaviour is expected or not. My difficulty was well identified by Servy, I think, it's a question of not making the question appear like a bug report. This is more concentrated on the self-answer variety and I agree with you, which is why I've found it so difficult to ask this sort of question before. Commented Feb 20, 2014 at 8:56

The two things to remember are:

  1. If there's a bug in a platform, there's also a solution the programmer will eventually implement, even if it means working around the platform.
  2. Asking [x] or [y] questions is less helpful, as it prompts answers like "it's [x/y]."

Everything else I write is simply a deduction from these two points.

As the question asker, it's your responsibility to write helpful questions. This means your questions should be open-ended enough for someone to (potentially) answer "it's not actually a bug," or give a more helpful response as to why it is a bug.

However, as you've noted, you can't really be completely confident, unless you've looked through the source and spotted the line (in which case, why are you asking a question?), that what you've found is a bug in the platform. The better way is to phrase the question so that the answerer can provide any form of solution.

The answerer has two responsibilities in this case. It's simply not good enough to say "this is a bug." Instead, the answerer should be looking to a solution for the problem. You know as well as I that solutions don't necessarily mean fixing the exact code at hand - the answerer should respond with this in mind, providing pointers which should help in either a) working around the problem, or b) creating a new and similar solution entirely (if succinctly possible).


Blatantly stating there is a bug in a major framework is usually a bad idea. For the most part this is the route inexperienced users take. It probably turns out that they didn't frobulate the barelator.

If it was truly a bug, then there is nothing anyone but the author of the related code can do to fix it. No answer from a non author will fix the bug.

What can potentially get fixed is the behavior the bug is causing. Stating the behavior that was expected but what actually happened can be beneficial because then answers can either address the bug (if it is will known), provide a workaround, an alternative, or all of these.

If you know the answer is a bug, then post the question anyway, but make sure that the behavior is the centerpiece of the question and give as much information on reproducing the behavior as possible. Others can benefit from those answers. If the answer truly is "this is not possible with the current version" then at least that reference is there as well.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .