Kdb 如何调试'；2019.01.01T01:01:01.3213141长度或不匹配错误

在我们的一个脚本中，出现了一个错误：

'2019.01.01T01:01:01.3213141 length 
'2019.01.01T01:04:34.3213141 mismatch

脚本相当大，我们所有的函数都进行了适当的调试。我假设这来自一个核心kdb函数。内置函数之一

我是否可以在kdb中进行任何更改，以显示执行了哪个函数，或者显示有关此错误来源的更多详细信息

---

更新：错误不相关

此信号不是kdb的默认样式，表示在脚本中以自定义方式抛出错误。当抛出信号时，错误已经以某种方式被捕获

我将研究如何使用错误捕获功能，您是否已经阅读了有关的文档？

，正如Callum所说，该页面对此非常有用

这看起来像是一个基本的tickerplant错误。我会将您的注意力集中在您在整个代码中使用的任何插入、追加或联接上

是否有伴随错误的日志记录语句？如果是这样，您可以尝试将错误发生的时间与错误发生前刚刚运行或正在运行的函数进行匹配

---

你熟悉吗？此功能在这里可能非常有用。

您是否有机会使用

daemonize

（或其他后台工具）启动kdb进程并重定向stderr？如果是这样的话，那么我相信这就是导致日志记录时间戳的原因（香草kdb只记录错误，而不是Callum提到的时间戳）。例如

当然，这并不能解决您的实际错误，只是可能解释了时间戳的混淆

对于您的实际错误-如其他响应所述，这些错误可能是由进入流程的格式错误的数据插入引起的：

length

表示字段计数不等于列计数，

mismatch

表示可能由于不同的数据类型或列而导致连接失败

要捕获错误，您有几个选项：

假设传入数据在流程中碰到

upd

（upert/insert）函数，请修改此

upd

函数以执行受保护评估以捕获故障。差不多

这将存储全局变量.err.x和.err.y。不要在生产tickerplant中执行此操作-在测试环境中重播数据

您可以采用一揽子方法捕获所有传入的.z.pg/.z.ps记录

---

同样，不要在生产系统中这样做，它应该仅用于测试/调试

100%，而不是来自我们的任何功能。我们使用一种非常不同的格式抛出错误，所有内容都在错误陷阱中并经过测试。我们唯一不使用保护性评估的是，例如，如果我们有一个.z或.u函数，并且我们向它添加了一些东西。例如.u.upd:{{stuff}.upd.custom}。“东西”并不是错误陷阱，但是通过每一个都会是一件痛苦的事情。有些东西干扰了信号的抛出，因为kdb信号是单个单词。如果您使用自己的错误报告机制，请使用它实现

.Q.trp

，并打印回溯。

/start background process
./daemonize -e ~/myerr.log -o ~/myout.log -p ~/mypid.log $QHOME/l64/q -p 5555

/send this process a bad message to create error
q)h:hopen`::5555
q)neg[h]"1+`a"

/check log
>tail -f myerr.log
'2019.11.07T04:47:51.610 type

upd:{.[insert;(x;y);{`.err.x set x;`.err.y set y;'z}[x;y]]};

.z.pg:{@[value;x;{`.err.pg set x;'y}[x]]};
.z.ps:{@[value;x;{`.err.ps set x;'y}[x]]};