You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Deno will always die on unhandled exceptions / rejections.
I'd like to request the ability to change this for uncaught promises.
I know a lot of people just say hey if this happens it is your fault. Technically your right. But this is reality. And people make mistakes. Production crashing because of a mistake is a serious issue. Especially when it is so easily preventable. But the problem really gets amplified when even if you are perfect, and your code catches everything and everyone, you can still crash if one of your deps forgets. So you can not just rely on yourself being perfect but the entirety of the world needing to be perfect. This in my opinion makes Deno very hard to want to use in production. Processes crashing are not an acceptable solution imo.
Let's take a look at a simple example. Please bare with me here.
In this example, what happens is the process crashes. Because the developer of that third party dep forgot to catch something. Now this could be god knows how many deps deep. So the argument that you have to check every line of your deps code isn't really possible realistically. Nor is having to check every single commit of every single dependecy. This just adds on to more reason of why Deno is impossible to use in production.
If this was nested some 10-15 levels deep, we would never be able to debug this and even attempt a fix.
This is all to say that Deno in production is really hard to vouch for. Realistically Deno is only usable in production if you do not use any deps for your projects.
Now for another point of view. Deno is realllllllly hard to use for beginners. A lot of users wanting to use my library are first time developers. This means they are just getting into their very first coding project EVER! I have made it as easy as possible for users like this to be able to get started. They can literally use the strictest TS settings without even needing to know a thing about typing or casting or anything. However, this 1 issue of them forgetting .catch is a serious issue.
Time and time again I have users reporting their processes crashing because they simply forgot to catch something. Not have a training wheel so to speak makes this really difficult. A simple handler to prevent crashes could be soooo useful because I could have this internally built for them so it alerts them of where they are forgetting to catch so that they can fix their code and prevent their processes from crashing.
The text was updated successfully, but these errors were encountered:
Duplicate of #7013. Discussion of whether or not it should prevent crashes should be taken there, since it's not precluded by the issue title/description.
Deno will always die on unhandled exceptions / rejections.
I'd like to request the ability to change this for uncaught promises.
I know a lot of people just say hey if this happens it is your fault. Technically your right. But this is reality. And people make mistakes. Production crashing because of a mistake is a serious issue. Especially when it is so easily preventable. But the problem really gets amplified when even if you are perfect, and your code catches everything and everyone, you can still crash if one of your deps forgets. So you can not just rely on yourself being perfect but the entirety of the world needing to be perfect. This in my opinion makes Deno very hard to want to use in production. Processes crashing are not an acceptable solution imo.
Let's take a look at a simple example. Please bare with me here.
In this example, what happens is the process crashes. Because the developer of that third party dep forgot to catch something. Now this could be god knows how many deps deep. So the argument that you have to check every line of your deps code isn't really possible realistically. Nor is having to check every single commit of every single dependecy. This just adds on to more reason of why Deno is impossible to use in production.
If this was nested some 10-15 levels deep, we would never be able to debug this and even attempt a fix.
This is all to say that Deno in production is really hard to vouch for. Realistically Deno is only usable in production if you do not use any deps for your projects.
Now for another point of view. Deno is realllllllly hard to use for beginners. A lot of users wanting to use my library are first time developers. This means they are just getting into their very first coding project EVER! I have made it as easy as possible for users like this to be able to get started. They can literally use the strictest TS settings without even needing to know a thing about typing or casting or anything. However, this 1 issue of them forgetting .catch is a serious issue.
Time and time again I have users reporting their processes crashing because they simply forgot to catch something. Not have a training wheel so to speak makes this really difficult. A simple handler to prevent crashes could be soooo useful because I could have this internally built for them so it alerts them of where they are forgetting to catch so that they can fix their code and prevent their processes from crashing.
The text was updated successfully, but these errors were encountered: