Question about req.multipart handler function error handling

[BobbyWibowo]

Just wondering, was it an intentional choice not to re-throw errors within the handler function into the initial req.multipart() Promise?

If I intentionally throw an error within the handler function to simulate random unexpected errors, neither try-catch around of, nor .catch on, req.multipart(), would capture said error
Instead it would only be captured by the global error handler I have for unhandled promise rejections, possibly because the handler is being called on a separate context or something along that line

e.g.

try {
  await req.multipart(async field => {
    throw new Error()
  })
} catch (error) {
  res.status(500).end() // not triggered
}

console.log('req.multipart() basically did not error out') // this logs
res.send('OK')

I guess I can just wrap the handler function itself with an error handler of its own, but it kinda feels odd

[kartikk221]

That was actually not intentional at all. It seems its a mistake on my end as I assumed that uncaught Promises inside of another Promise will automatically be caught by the top level promise. I just pushed a commit to resolve this issue. Let me know If the fix pushed in commit resolves your issue.

[BobbyWibowo]

As of commit ed69ecb, it almost worked

If I do something similar to the code snippet in the original post, errors from within the handler function will indeed be caught now

But then, if I were to end the request, either via leaving the errors to be caught by the function provided in Server.set_error_handler(), OR almost immediately after Request.multipart() by doing Response.end(), the following errors will always throw:

[23:03:02] Uncaught Exception: Error: Unexpected end of file
    at checkEndState (/home/bobby/src/safe.fiery.me/node_modules/busboy/lib/types/multipart.js:609:24)
    at Multipart._destroy (/home/bobby/src/safe.fiery.me/node_modules/busboy/lib/types/multipart.js:576:13)
    at _destroy (node:internal/streams/destroy:102:25)
    at Multipart.destroy (node:internal/streams/destroy:64:5)
    at Multipart.Writable.destroy (node:internal/streams/writable:866:11)
    at finish (/home/bobby/src/safe.fiery.me/node_modules/hyper-express/src/components/http/Request.js:614:26)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
[23:03:02] Uncaught Exception: Error: Unexpected end of form
    at checkEndState (/home/bobby/src/safe.fiery.me/node_modules/busboy/lib/types/multipart.js:612:12)
    at Multipart._destroy (/home/bobby/src/safe.fiery.me/node_modules/busboy/lib/types/multipart.js:576:13)
    at _destroy (node:internal/streams/destroy:102:25)
    at Multipart.destroy (node:internal/streams/destroy:64:5)
    at Multipart.Writable.destroy (node:internal/streams/writable:866:11)
    at finish (/home/bobby/src/safe.fiery.me/node_modules/hyper-express/src/components/http/Request.js:614:26)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)

The request did end properly however

[BobbyWibowo]

The function I provide into Server.set_error_handler() basically does the same thing, in that it will end the request immediately (just with some error formatting and whatnot), so that fact isn't really relevant I suppose

[kartikk221]

The above problems should be fixed in the recently released v6.3.0 version of HyperExpress.

[BobbyWibowo]

Can confirm! Thank you!