Hi France,
It has been a few days. I'm sorry if in my last response I jumped to conclusions about your code too fast and went into a kind of sermon on software development. I couldn't draw these conclusions from the code you shown. Only defense I have is that shortly after I fell ill and was off-line for a most of the week, so maybe I was already affected ;-)
I'm still not sure if what you're asking for is purely for debugging so you can fix the root cause in the code, or if this is an application issue/exception in the processed files that you want to handle within your normal application logic. Some of your comments suggest the latter whereas traceback stuff etc. is meant for the former.
Regarding the tracebacks: I think that if performance is too much affected by this trace with bound variables it should definitely be an option that you can switch off. Also wouldn't it help (or maybe it amounts to the same, I don't know) to have an option to do dumps of bound variables and possible traceback info to a file whenever something goes awry.
--Marc
On Thu, Aug 21, 2014 at 3:55 PM, Christian Grün christian.gruen@gmail.com wrote:
If that means that I may get thousands of XML files in the trace when batch processing, it seems I would get so much information that what ever is relevant would get lost in the mess.
It would mean that all variables would be bound to a map in an additional error variable (e.g. $err:variables), and you could freely choose the information that seems relevant to you.
We would be concerned if it ended up having an impact on performance. We worked hard to improve on that front.
Sure; we'd only add such a functionality if it won't have negative effects on performance.
Regarding your first mail in this thread, I'm probably still not sure what the extension you are asking for should do, and how it should look like. If you have a concrete idea how the function could be called, or could look like, feel free to propose it here.
Christian
On Thu, Aug 21, 2014 at 6:16 AM, Christian Grün christian.gruen@gmail.com wrote:
Some time ago, Charles Foster had the idea that all bound variables should be added to the stack trace whenever an error occurs [1]; would that be helpful? Before implementing this, however, we would need to think of various issues related to performance (try/catch statements will get slower when variables are bound to the stack every time; large XML snippets that will not be garbage-colected when being bound to an error; database references are not available anymore when an error is raised, etc.).
[1] https://github.com/BaseXdb/basex/issues/831
On Mon, Aug 18, 2014 at 9:39 PM, Andy Bunce bunce.andy@gmail.com wrote:
Hi France,
I think this is not possible, but I think it would be a good thing! I think it is related to Marc's query about call an anonymous function with a variable argument list [1]
XQuery provides no access to the stack. But..I can see that one could implement a new function maybe in the BaseX profiling module [2] that returns a map. The keys would be the argument names of the function being executed and the values those of the current arguments.
All that is required is to implement it :-)
/Andy
[1]
http://www.mail-archive.com/basex-talk%40mailman.uni-konstanz.de/msg04539.ht... [2] http://docs.basex.org/wiki/Profiling_Module
On 18 August 2014 18:14, France Baril france.baril@architextus.com wrote:
Hi,
I'm working on improving our tracking capabilities. I was hoping to find a function that would do the equivalent of what the code bellow does, but for internal functions that are not called through the rest interface.
string-join(for $name in request:parameter-names() return $name || ': ' || string-join(request:parameter($name), '; '),
' ')In short, I was wondering if there is way I can read the function's parameters and their values without listing each one explicitly.
I searched the documentation without success.
-- France Baril Architecte documentaire / Documentation architect france.baril@architextus.com
-- France Baril Architecte documentaire / Documentation architect france.baril@architextus.com