₦airaland Forum

.

I think set timeout() is asynchronous and registers an event that is handled by the libuv . Place another try-catch inside your setTimeout async block

It is working exactly as it should... you're sending a message but nowhere to receive it.


You need to add Onmessage listener in your contentScript, PopUp or the Background itself

Paystack:
It is working exactly as it should... you're sending a message but nowhere to receive it.

Are you even a developer? What then is the purpose of a try catch block?

chukwuebuka65:
Are you even a developer? What then is the purpose of a try catch block?

You asked it to console the error which it is clearly doing.

I'm not a developer


The block tried your faulty code it didn't work

It then catch it and spilled the trash out to u

Paystack:
It is working exactly as it should... you're sending a message but nowhere to receive it.


You need to add Onmessage listener in your contentScript, PopUp or the Background itself

That’s not the issue. I know why the error is happening . My question is why the catch block is not catching the error and logging it to the console.

.

Paystack:
You asked it to console the error which it is clearly doing.

I'm not a developer


The block tried your faulty code it didn't work

It then catch it and spilled the trash out to u

The second pics is not the console, it’s the extension management tab. The console is empty

richebony:
I think set timeout() is asynchronous and registers an event that is handled by the libuv . Place another try-catch inside your setTimeout async block

This worked. But why ?

chukwuebuka65:
This worked. But why ?

I think I explained in the preceding text, the setTimeout function is asynchronous and isn't a native js function, and your callback function is invoked on a different execution context because its the libuv [c++] APIs that nodejs delegates the timer function to. So your try-catch block isn't bound to your callback function because it exists in a different execution context

richebony:
I think I explained in the preceding text, the setTimeout function is asynchronous and isn't a native js function, and your callback function is invoked on a different execution context because its the libuv [c++] APIs that nodejs delegates the timer function to. So your try-catch block isn't bound to your callback function because it exists in a different execution context

Nice

richebony:
I think I explained in the preceding text, the setTimeout function is asynchronous and isn't a native js function, and your callback function is invoked on a different execution context because its the libuv [c++] APIs that nodejs delegates the timer function to. So your try-catch block isn't bound to your callback function because it exists in a different execution context

Ok makes sense. Thanks

rich-ebony is correct in a way, but also you're sending a post-message, the source isn't sure whether to close it or not, because it is not informed of what to do,

from the onMessage handler you send a sendResponse back so that it will close. That is the Chrome extension architecture around post-messaging.

try it, i faced alot of that too

qtguru:
rich-ebony is correct in a way, but also you're sending a post-message, the source isn't sure whether to close it or not, because it is not informed of what to do,

from the onMessage handler you send a sendResponse back so that it will close. That is the Chrome extension architecture around post-messaging.

try it, i faced alot of that too

Alright boss.