Improved error reporting in stacktrace

[elight]

trafficstars

Is your feature request related to a problem? Please describe. When an error occurs within Dataview, particularly DataviewJS, the provided stacktrace often does not indicate a useful location or nature of the failure. This is a particular problem when writing DataviewJS on any platform that does not provide a browser developer console. However, it is still a problem even with the developer console.

Describe the solution you'd like Improve exception reporting from Obsidian such that:

1. Failures to interpret provided DataviewJS and runtime failures of executing DataViewJS result in: a. The line of text that failed to interpret b. The error thrown by the interpreter
2. This information is displayed inline in the output from the dataview block.

Describe alternatives you've considered

1. For mobile development, commenting out chunks of the code, adding dv.span statements as a DataView equivalent of console.log. Tedious and painful. Not recommended.
2. Minimize the need to develop within Obsidian DataviewJS code blocks by more easily supporting and encouraging the extraction of business logic into separate files. E.g., create a framework to separate Query, Rendering, and Business Logic, such that Vault queries and document changes can be kept entirely separate from the business logic of transforming the data. This allows the Business Logic to be developed in a DV-agnostic way, as "plain old JavaScript", outside of Obsidian, including using all of the attendant automated testing tools and best practices many devs are accustomed to. NOTE: Nothing prevents individual DV users from doing this. I'm suggesting this could be useful guidance, and supported by a framework, as (perhaps) more people adopt DVjs.

[AB1908]

Some stuff has improved on the Obs side iirc. Does the insider build address any of these concerns?

[blacksmithgu]

Obsidian has improved this a bit - I think to truly get good logs, I need to find an alternative JS execution library that is better than plain eval. Maybe new Function() { ... } is better?

[elight]

Some stuff has improved on the Obs side iirc. Does the insider build address any of these concerns?

It does not seem to. I've been using insider builds exclusively for the past month or so.