Timeline for How to convince team members of the existence of a "mandelbug"
Current License: CC BY-SA 3.0
30 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 6, 2013 at 6:43 | comment | added | Erik Reppen | So.. wait. What do they think? That you typed in the stack trace manually? | |
| May 30, 2013 at 21:09 | answer | added | Karl Bielefeldt | timeline score: 2 | |
| May 30, 2013 at 13:08 | history | edited | gnat | CC BY-SA 3.0 |
mandelbug += http://en.wikipedia.org/wiki/Mandelbug "what's this"
|
| May 30, 2013 at 12:25 | answer | added | John R. Strohm | timeline score: 2 | |
| May 30, 2013 at 10:46 | vote | accept | fithu | ||
| May 30, 2013 at 10:32 | comment | added | Giorgio | @Doc Brown: I had nowhere stated that a line throwing an exception is the root cause of the bug. On the other hand, a crash and a stack trace show that there is a bug somewhere and the other developer is wrong in saying that there is no bug. IMO a good approach is that the two developers analyze the bug together. | |
| May 30, 2013 at 8:49 | comment | added | fithu | @Giorgio, flaming letters on the wall? Voice from the skies? | |
| May 30, 2013 at 8:22 | comment | added | fithu | Just a network error(s), nothing is wrong on the server side. I'm afraid he is not going to collaborate. "This is not a bug" | |
| May 30, 2013 at 8:18 | comment | added | Giorgio | @Doc Brown: Handling the exception on the client (e.g. by showing a warning message to the user) would not solve a problem that occurs on the server side. I think the other developer should at least collaborate to analyze the exception and understand what causes the error. | |
| May 30, 2013 at 8:11 | comment | added | fithu | @Doc Brown, network error makes this exception be thrown. Sincerely yours, C.O. | |
| May 30, 2013 at 8:10 | comment | added | Doc Brown | @fithu: really? the way you wrote it makes me understand not the network error is the root cause, but the missing exception handling for it. | |
| May 30, 2013 at 8:08 | comment | added | fithu | @Doc Brown, network error in a very specific period of time and state of the program, that is the root reason. And root reason is not my problem - that developer refuses to admit this bug even exists. | |
| May 30, 2013 at 8:07 | history | tweeted | twitter.com/#!/StackProgrammer/status/340016593104928768 | ||
| May 30, 2013 at 8:04 | comment | added | Doc Brown | @Giorgio: a stack trace is a proof that a program can crash at a specific line, it does not proof that this line is the root cause of the bug. That seem to be the fact the OP seem to have misunderstood, and the cause why I had problems to understand some question details. | |
| May 30, 2013 at 8:01 | answer | added | Doc Brown | timeline score: 10 | |
| May 30, 2013 at 8:01 | comment | added | Giorgio | @fithu: If a developer cannot be convinced with a stack track, what else should convince him. | |
| May 30, 2013 at 7:36 | comment | added | Doc Brown | @fithu: I take this comment as "though I have the source code of the lib available, I did not pinpoint the bug cause in the library code". If I got you correct, you cannot know if the "bug is easy to fix", as you wrote above. And it is completely understandable then that the dev of that lib refuses to change anything without a reproducible test. Either you find a way to do "the impossible", or you go through the library code by yourself, point with the finger at the exact line of code and ask the other dev kindly to change that line. | |
| May 30, 2013 at 7:29 | comment | added | fithu | @Doc Brown, as I already wrote, I reproduced it once, but reproducing it whenever you want is impossible. | |
| May 30, 2013 at 7:25 | comment | added | Doc Brown | @fithu: you clearly misunderstood me - the attribute "not constructive" referred to the fact that you gave me that kind of answer (instead of investing your time in editing your question to make it more clearer). But you still did not answer my question - did you pinpoint the bug in code, or did you not? | |
| May 30, 2013 at 6:59 | answer | added | dodgy_coder | timeline score: 2 | |
| May 30, 2013 at 6:37 | history | edited | yannis | CC BY-SA 3.0 |
added 7 characters in body
|
| May 30, 2013 at 6:34 | comment | added | Doc Brown | @fithu: your original title was some kind of rant against your boss. I changed it in hope it prevents the soon closing of your question, rants are not very popular on this site. If the new title don't reflect your question correctly, feel free to improve it further. | |
| May 30, 2013 at 6:32 | history | edited | Doc Brown | CC BY-SA 3.0 |
gave the question a more constructive title
|
| May 30, 2013 at 6:25 | comment | added | fithu | @Giorgio, copied stacktrace text from VS | |
| May 30, 2013 at 6:23 | comment | added | Doc Brown | @fithu: you are a little bit too convinced that reproducing such kind of bug is impossible - it may be hard, but seldom "impossible". And how can you know that the bug is "easy to fix" when you don't have access to the source code? Just catching an exception might not really fix the problem. Or are you talking about library code you have access to, and you already pinpointed the exact line where the bug occurs? If so, why don't you suggest a fix in code? | |
| May 30, 2013 at 6:15 | comment | added | Giorgio | Have you saved the stacktrace in some form? E.g. do you have a screenshot of your IDE showing the stacktrace of the crash? | |
| May 30, 2013 at 5:33 | review | First posts | |||
| May 30, 2013 at 6:36 | |||||
| May 30, 2013 at 5:32 | answer | added | Manoj R | timeline score: 34 | |
| May 30, 2013 at 5:25 | comment | added | Charles Sprayberry | I'd say it is pretty simple. Create a unit test that proves what you're saying is true. | |
| May 30, 2013 at 5:17 | history | asked | fithu | CC BY-SA 3.0 |