Handle nil error message for the REPL

[igorlfs]

Hello!

This fixes a small regression introduced in 5766946

Some adapters may return errors that when parsed by utils.fmt_error return nil (in spite of not being nil themselves), which throws an error in M.append.

An example is getting the value of a non-declared variable with the js-debug-adapter.

[mfussenegger]

Thanks, could you also update the annotations?

I also wonder if instead there should be a fallback in the __tostring implementation, then the full diff could look like this:

diff --git a/lua/dap/protocol.lua b/lua/dap/protocol.lua
index 59ccac1..23e5282 100644
--- a/lua/dap/protocol.lua
+++ b/lua/dap/protocol.lua
@@ -24,11 +24,11 @@
 ---@field message? "cancelled"|"notStopped"|string
 ---@field body? any
 
 
 ---@class dap.ErrorResponse: dap.Response
----@field message string
+---@field message? "cancelled"|"notStopped"|string
 ---@field body {error?: dap.Message}
 
 
 ---@class dap.Message
 ---@field id number
diff --git a/lua/dap/session.lua b/lua/dap/session.lua
index abc1d86..226d4c6 100644
--- a/lua/dap/session.lua
+++ b/lua/dap/session.lua
@@ -14,11 +14,11 @@ local mime_to_filetype = {
   ['text/javascript'] = 'javascript'
 }
 
 local err_mt = {
   __tostring = function(e)
-    return utils.fmt_error(e)
+    return utils.fmt_error(e) or "Undefined error"
   end,
 }
 
 
 local ns_pool = {}
diff --git a/lua/dap/utils.lua b/lua/dap/utils.lua
index a8a37ce..575dc91 100644
--- a/lua/dap/utils.lua
+++ b/lua/dap/utils.lua
@@ -1,10 +1,10 @@
 local M = {}
 
 
 ---@param err dap.ErrorResponse
----@return string
+---@return string?
 function M.fmt_error(err)
   local body = err.body or {}
   if body.error and body.error.showUser then
     local msg = body.error.format
     for key, val in pairs(body.error.variables or {}) do

Because if tostring on the err can return nil some of the other usages might also cause issues

[igorlfs]

I also wonder if instead there should be a fallback in the __tostring implementation

That does sound like a better approach! I've applied your patch and rebased. Let me know if anything else is necessary.

[mfussenegger]

I also wonder if instead there should be a fallback in the __tostring implementation

Let me know if anything else is necessary.

All good, thanks