presenter invoke 返回值问题

[zfangqijun]

src/renderer/src/composables/usePresenter.ts

return await window.electron.ipcRenderer
            .invoke('presenter:call', presenterName, functionName, ...rawPayloads)
            .catch((e: Error) => {
              console.warn(
                `[Renderer IPC Error] WebContents:${webContentsId} ${presenterName}.${functionName as string}:`,
                e
              )
              return null
            })

@zerob13
哈喽，打扰一下
我正在使用 deepchat 做二次开发
想问下，是出于什么考虑 presenter:call 时，遇到异常 return null 呢
因为这会破坏 promise 调用链，无法 catch，不得不判断 result 处理异常
main 暴露的接口也得避免 return false/undefined/null/0 等

[zerob13]

其实目的就是不想在ipc的链路里面抛异常出来。因为如果正确去处理这些异常的话，其实会有非常多的问题要去兜底，整个程序的调用链路是比较长的，ipc这层的异常稍微处理不好就会引起main和renderer都出问题。
当然这不是一个好设计，只能说是目前偷懒的一些妥协。（让我有更多的注意力在写功能上。。。🫣）

[zfangqijun]

其实目的就是不想在ipc的链路里面抛异常出来。因为如果正确去处理这些异常的话，其实会有非常多的问题要去兜底，整个程序的调用链路是比较长的，ipc这层的异常稍微处理不好就会引起main和renderer都出问题。 当然这不是一个好设计，只能说是目前偷懒的一些妥协。（让我有更多的注意力在写功能上。。。🫣）

看了renderer对presenter的调用，明白你的用意了。

有意PR一个，对 usePresenter 加入 safeCall 参数，默认 true，兼容现有逻辑，当设置为 false 时不做 return null。
你觉得是否合适？

[zerob13]

其实目的就是不想在ipc的链路里面抛异常出来。因为如果正确去处理这些异常的话，其实会有非常多的问题要去兜底，整个程序的调用链路是比较长的，ipc这层的异常稍微处理不好就会引起main和renderer都出问题。 当然这不是一个好设计，只能说是目前偷懒的一些妥协。（让我有更多的注意力在写功能上。。。🫣）

看了renderer对presenter的调用，明白你的用意了。

有意PR一个，对 usePresenter 加入 safeCall 参数，默认 true，兼容现有逻辑，当设置为 false 时不做 return null。 你觉得是否合适？

当然非常欢迎，很合适，但是可能建议稍微等个半个月，目前整体结构再做大型重构，或者直接可以基于 feat/new-thread-mock 这个分支去进行修改