I’m sure I’m missing something obvious but can’t understand the lack of line numbers for error controls.
I’m adding try catch statements to the code and using runtime exceptions, in case of any error I can read the stack and get some info but if more than a few lines are involved I need to try to reproduce the error in debug mode to find out the line.
I know that without the try’s debugging points me to the error but what if the try’s are already coded? Why not just add line numbers to get this crucial info?
Also I would greatly appreciate them when comparing to the Windows version of code in visual studio.
How goes the usual bug report that I get. My logs tell me NilObjectException in method so and so. Then I look over the method and don’t see where something could be nil. So I pepper the method with additional numbered log statements, make a new version and upload it for the customer to test. If I’m lucky the next error log will tell me at which location the NOE happened. Now if I had the exact line of code the first round of troubleshooting would be a bit easier.
Ideally, what you want report is the exception and what caused it. So if I get a report that says I got an Nil Object Exception I’d like to know what bit of code or object caused the problem. Right now the only thing we get is the NOE and it’s up to us to track it down.
The request for line numbers is simply a way to help us track down bugs. If a superior solution to line numbers was given to us we would gladly use it.
Frankly, the current system forces me to create smaller methods than I might normally do. This limits the exposure of any method This is isn’t a bad thing but it doesn’t solve the real issue we all experience.
Pretty sure the exception quite literally doesn’t have a clue what source code line it came from and that information is not preserved in the compiled code. When your code is compiled it would have to turn into something roughly like
[code]- set line #
run all the machine code generated from that line
this could be hundreds of instructions, method calls, framework calls, etc
set line #
run all the machine code generated from that line
this could be hundreds of instructions, method calls, framework calls, etc[/code]
and so on so that it can track what source line the exception was generated on.
Right now the line # is not preserved into your compiled code (Joe might have to correct me on this but I’m pretty sure its not)
And IF you alter the code after you compile the line # is not going to be very useful as it might point you to the wrong line.
Its literally “this line with this exact set of source code”
Which is what VS adds (line #'s and pointers to the executable code, among other things) when adding “debug info” to the compile. While testing, you can get the line number and plenty of other useful information when there’s an exception. Once the program is fully tested and debugged, you’re free to turn off that compile option to optimize the app. Great for giving to beta testers or any user that runs into a problem that’s difficult to reproduce.
Would VERY much appreciate it if Xojo had an option like this!
For this a constant LINE like in c would be helpful.
Like CurrentMethodName.
Although that is just a dump constant.
A line number constant must be evaluated when tokens are parsed to work.
I think I would be relatively easy to get line numbers developed for 90% of the NOE.
out of bounds would only get them when the check is done inline, which it currently is not.
Line “number” not withstanding… .it would be nice if Xojo could narrow it down to within a few lines… instead of having to decypher a exception log and guess. I refactored a ton of classes recently, and had to track down hundreds of NOE due to not properly setting certain values in the new normalized classes… Finally got it all working, but if Xojo would have been able to say “NOE on line x”. it would have taken minutes not hours
the line # that a specific set of instructions in LLVM come from is not propgated through the front end and back end
not trivial to add from what I recall when Joe & I discussed this
If I can’t find what caused an exception reported by a customer, I use a little utility I wrote that adds line number statements (i.e. LineNum=12 or whatever) into the problematic method every few lines of code or so. I then do a beta build or include it in a regular release, on the assumption the bug will pop up again eventually. When the exception is raised, there’s code in my exception handler that reports the exception, the name of the module and the method, and the value of the LineNum variable. Oddly enough, it doesn’t seem to slow down code execution to any significant degree, and it sure helps when finding bugs. It’s primitive and it makes code sometimes hard to read, but I also have a matching app that can remove the line numbers.
