On Monday, December 22, 2014 4:45:05 PM UTC-8, Alex Glaros wrote: > > I searched the error ticket for traces for table name, line number, but > couldn't see any connection to anything regarding the real error (which I > knew) >
The easy bugs are the ones that break right where the mistake is. Not all bugs are that polite. If the problem is occurring due to recent code changes, then you can use your source control bisection tools to track down which version introduced the problem. That helps to focus you on what is *usually* the right area. I say "usually", but sometimes the change doesn't *introduce* the bug, it merely *uncovers* it. When things break because a bug is uncovered, it's usually hiding in old code that you thought was working just fine. And it was, until the planets aligned to produce just the precise input, or traffic on the highway hit just the right speed to put the race cars in contention. About all you can do for these bugs is look at where the break occurred, and try to determine what assumptions are being made, and what code is responsible for enforcing those assumptions. Also, bring along some dice and use the rolls to pick a line number to look at. Note that print/log statements often help, as do debuggers, but they do change what is happening and can alter the sequence, and can make a bug disappear before you tag it. At least, that's my thoughts on the subject at the moment, shooting from the hip on a day off. /dps -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
