Now that we have a smart script workspace with line numbers, this feature would return the line # of the script step that produced the error.
This would be really helpfull to debug scripts with multiple lines
Instead of a function, I would suggest maybe that the last error script + line number could be shown in the debugger.
A better solution would be named script blocks
I agree with the underlying motive behind the suggestion, airmoi—it was raised in the "Try…On Error…End Try" discussion, as well—but worry that it would be brittle, as line numbers constantly change. They're really not useful for much of anything other than temporary reference ("hey, take a look at line #92 and see if you can help me figure out why it's failing.").
Here is one thought that might make them work. The idea is just off the top of my head, so am not sure I endorse it, but getting it down in black and white is a first step toward thinking it through (collectively?)…
Perhaps the Get ( LastErrorLine ) function could be paired with another new function, GetLineNumber ( lineNumber ). The latter would protect hard-coded line-number references from breaking in the same way that GetFieldName ( ) does for field names. Then, in an error handling block of code, you'd reference things this way:
If [ $error = 301 and Get ( LastErrorLine ) = GetLineNumber ( 143 ) ]
That is an interesting approach, but I though the issue of it being too brittle isn't really that significant. When you couple the line number and an error code, it's not typically going to be hard to locate what the problem is.
If you modified the script so the line numbers are different, then the error conditions also potentially changed, and you need to re-test. I think this is most useful for people who are immediately debugging a problem.
For developers that might look at a log with error line numbers that happened months ago, there is a good chance that they also are the type of person that archives periodic DDR exports. I regularly use multiple DDR versions to compare script source to see when/how a bug was introduced.
I don’t think get( LastErrorLine) is a useful function at all to have in FileMaker calculations - it will only entice developers to write bad code that quickly breaks!
However , it is very useful to have this information in the debugger!
=> I would thus suggest that the LastErrorLine (...and LastErrorScript and LastErrorFile...) be shown in the debugger.
Thus, when the debugger stops or reaches a breakpoint (say at the end of a script / after the End-If / or in the line after a script call ), it should be possible to find out which line of which script in which file the error occurred.
Instead of adding another function, why not add a new script step and extend the existing Get ( LastError ) function, as proposed here: Set Error Capture setting: Verbose?
The upshot: Set Error Capture [ On; Verbose ] would tell FileMaker to return more information to Get ( LastError ), including Script Name and Line Number, when an error is encountered.
I think you missed the point about this feature
The Idea behind that is to be able to log errors (like in a log table) for example with a more details (all languages supporting error trapping give infos like filename and line of the error or stacktraces usefull for debugging).
A concrete example is on a "migration" script that would run many imports, such a script may be very long.
It would be much easier to debug if we could get the line where an import failed
Never though about using such code as "Get ( LastErrorLine ) = 140", that would be completely dumb....
Retrieving data ...