code line numbers and errors

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.

This is in one of my not so old feature requests: <>

In the code editor, if you hover the mouse over a line of code, the row and column are displayed with the code tip (below the code editor).

Greg, I think he’s specifically talking about line numbers for exceptions. NOT in the code editor.

@Greg: I think that Bob is correct.

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”

I didn’t say it was possible. I just said “ideally”. If I could get any additional detail from an exception it would be most welcome.

Well damn … seems in editing my own reply before I posted it I left out the important

This may change in the new compiler

part :stuck_out_tongue:

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!

Most NOE are generated in the method inline.

And for those they could pass line numbers.

Basically for every call you write like this


Xojo generates an

if o = nil then Raise exception Else call test(o) End if

I even suggested Geoff months ago to make such changes voluntarily…

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.

For NOE, VS has a great feature, the ?.

SomeVar = o?.Test

if o is nil, the function is ignored.

Like this? <>

Yes, that feature request is good.

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.