Server should not shutdown when there is an error about uwebsockets.js

This whole thread blows my mind. With 15, maybe 20 years background in C++ I really will never get how a scripter's mind sticks together.

It's like demanding to be able to cook eggs using your door bell.

[aadityataparia]

Examples:
JS Exceptions -

      res.end({ user: 1 });
          ^

TypeError: res.end is not a function
    at /users (/Users/aaditya-taparia/Personal/sifrr-api-demo/routes/user.js:11:11)
Assertion failed: (err == 0), function uv_loop_delete, file ../deps/uv/src/uv-common.c, line 691.
[1]    75960 abort      node wsserver.js

Like other servers, I think it should not abort, rather should just show error in console and continue listening.

And when there is an error in underlying c code, there is no stack trace, and server just stops.

Server is running on localhost:2222
µWebSockets ill-use: Returning from a request handler without responding or attaching an abort handler is forbidden.
libc++abi.dylib: terminating
[1]    79105 abort      node wsserver.js

@musicformellons No this project is not the old "uws".

[porsager]

Yeah, and be sure to have logging in place so that you have some clues for how to fix the error when time allows it ;)

[porsager]

Ah, no I think that would be way out of scope, and there are already plenty of ways to handle this in a library/runtime agnostic way ;) - os service systems like systemd or node specific ones like pm2 or forever.

[porsager]

@alexhultman Well being a first time user of a doorbell, maybe expecting eggs to be ready after the ring isn't so crazy ;)

Yeah anyways, glad we came to some understanding at least 👍

How do you mean? Error? There's no error?

Exceptions? You can catch them.

Errors? I don't know?

[musicformellons]

I ran into this issue. Looks like uws errors and 'chokes' the container, which makes it hard to debug. So might be related.

@musicformellons That's not relevant here, you're using 2 year old code.

µWebSockets ill-use: Returning from a request handler without responding or attaching an abort handler is forbidden.
libc++abi.dylib: terminating

This is not an error, that's telling you you're using the lib in wrong ways. Read the text and fix. It should terminate if you have this issue. It's terminating the server because otherwise you will get strange bugs later on, and crash eventually.

The TypeError: res.end is not a function that's not completely correct, it should throw a different exception. I will check that. You probably need to do JSON.stringify({lalal})

This is what I get:

/home/alexhultman/uWebSockets.js/examples/HelloWorld.js:11
  res.end({val: 'Hello World!'});
      ^
Text and data can only be passed by String, ArrayBuffer or TypedArray.
node: ../deps/uv/src/uv-common.c:686: uv_loop_delete: Assertion `err == 0' failed.
Aborted (core dumped)

So what you want is basically a stack trace if a thrown error is not caught? Shouldn't an uncaught exception terminate the entire process?

[musicformellons]

Ok. Actually it now works after downgrading to node 8, so that's nice. I am a bit lost in the 'maintenance for uws' discussion..., could I just 'make' this library and it might work with socket.io (sorry, I am a mere mortal who has this as a dependency)?!

There's really not that big of a difference compared to how Node.js throws and terminates:

/home/alexhultman/uWebSockets.js/examples/HelloWorld.js:6
const app = uWS./*SSL*/App({
            ^

ReferenceError: uWS is not defined
    at Object.<anonymous> (/home/alexhultman/uWebSockets.js/examples/HelloWorld.js:6:13)
    at Module._compile (internal/modules/cjs/loader.js:688:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:699:10)
    at Module.load (internal/modules/cjs/loader.js:598:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:537:12)
    at Function.Module._load (internal/modules/cjs/loader.js:529:3)
    at Function.Module.runMain (internal/modules/cjs/loader.js:741:12)
    at startup (internal/bootstrap/node.js:285:19)
    at bootstrapNodeJSCore (internal/bootstrap/node.js:739:3)

There's no need to have a stack trace in these cases, because.... there's no one. This is not a JS lib, so showing a large JS stack trace is impossible as you literally are being called directly from C++. It's not like Node.js where you have a big fat callstack in JS to show. How hard is it really to look at the error and fix the issue? It shows you the exact line and why it failed I don't get why this would not be enough?

Like other servers, I think it should not abort, rather should just show error in console and continue listening.

That would be insane. You're talking about behavior basically like Visual Basic 6.0 "on error resume next" basically "catch all exceptions and ignore them happily". That's nonsense.

[aadityataparia]

@alexhultman Can you please provide an example on how to catch the exceptions and prevent server from terminating?

Have you tried try catch? It works for me.

However,

The entire point of these exceptions IS to enforce the user to correct their code. This lib will only throw exceptions when you make invalid use of the library (such as giving it wrong types).

If I try catch my invalid type passed to res.end and print the exception I get this:

Listening to port 9001
Text and data can only be passed by String, ArrayBuffer or TypedArray.
Text and data can only be passed by String, ArrayBuffer or TypedArray.
Text and data can only be passed by String, ArrayBuffer or TypedArray.
Text and data can only be passed by String, ArrayBuffer or TypedArray.
Text and data can only be passed by String, ArrayBuffer or TypedArray.
Text and data can only be passed by String, ArrayBuffer or TypedArray.
Text and data can only be passed by String, ArrayBuffer or TypedArray.

It is obvious the program is wrong, it clearly states that you are passing wrong type.

[aadityataparia]

I am not against showing exceptions, that is obviously best. But what I am unsure about is, why abort server on exception, why not show exception and keep server running?

All exceptions in all languages ever made will terminate the process if not caught. Since you are not wrapping what you do wrong, in try catch, it will terminate. That's how exceptions work.

try {

res.end(my insane type);

} catch () {}

Now it won't terminate

I think you are mixing two different things here - JS exceptions vs. that one hard terminate thing. Consider the terminate thing a cash with a message.

Look at VideoStreamer example, that's how it should be written

[aadityataparia]

#32 (comment) This would mean I will have to wrap every res.end for every endpoint with a try catch block?

No. You're not listening to what I'm telling you.

• Crash with reason = good.
• Crash without reason and without deterministic behavior = bad.

[aadityataparia]

🙏

[aadityataparia]

And what I am saying is, crash with JS exception = bad

[porsager]

@aadityataparia The key here is "unhandled/uncaught" exceptions. If you don't specifically handle the exception, the process should exit. The reasoning behind why this is the right thing to do has already been covered many times along with ways to handle it. Try to see if you can find writings about it by searching google - I did a quick search and this was the first I found - https://shapeshed.com/uncaught-exceptions-in-node/

#32 (comment) This would mean I will have to wrap every res.end for every endpoint with a try catch block?

No, this means that you should use the library as intended and only pass accepted types to res.end(). The solution for res.end({ user: 1 }) surely isn't to wrap it in try catch, but rather to fix the code eg. res.end(JSON.stringify({ user: 1 })).

When you set up your thing in production you will want to run your app with something that can ensure it is started again in the case an unhandled exception actually occurs (because none of us are perfect, and unexpected things can happen).

[aadityataparia]

Hmm.. makes sense, so I guess I should restart the server on an error.

[aadityataparia]

Yeah, logging is important. I was just hoping that restarting server or not exiting at all can be handled by uWS 🙇 Maybe not!

Okay but saw a board using nothing but mustard?

Fly to the moon using your dishwasher

[porsager]

It'd make a great Disney cartoon!

[aadityataparia]

😂 Sorry for having such expectations!