11–20 of 31 posts
Article describes try/finally as a hack to get the effect of defer, but it looks to me like it's the other way around? Try/finally is more traditional, in one form or another.
Article describes try/finally as a hack to get the effect of defer, but it looks to me like it's the other way around? Try/finally is more traditional, in one form or another.
Finally isn't bullet proof. If you execute a promise in a try block and it happens to end without resolving, the finally block will be never be executed. Fun stuff.
One can just wrap os.Exit in a helper to get the expected behaviour.
Earlier quoted context omitted.
Finally isn't bullet proof. If you execute a promise in a try block and it happens to end without resolving, the finally block will be never be executed. Fun stuff.
defer isn't bullet proof either. I think there's a linter about it and os.Exit. One can just wrap os.Exit in a helper to get the expected behaviour.
Article describes try/finally as a hack to get the effect of defer, but it looks to me like it's the other way around? Try/finally is more traditional, in one form or another.
Finally isn't bullet proof. If you execute a promise in a try block and it happens to end without resolving, the finally block will be never be executed. Fun stuff.
``` async function run() { try { await new Promise(() => { // The executor function finishes, // but it never calls resolve() or reject(). }); } finally { console.log("cleanup"); } } ```
I never expect cleanup to be logged.
Article describes try/finally as a hack to get the effect of defer, but it looks to me like it's the other way around? Try/finally is more traditional, in one form or another.
If the idea of computers is that they remember stuff for you and do stuff for you, then both try/finally and defer seem like hacks to work around not having RAII like e.g. Rust or C++ where resources are closed/disposed of/deallocated automatically. Try X finally dispose of all resources. X, defer clean up X. Or how about just X and cleanup is done automatically, with the author of the resources deciding what is need…
RAII doesn't really fit into every language because they don't all have deterministic destructors/finalizers and objects with scoped lifetimes. Sometimes you only have one but not the other and you definitely need both.
Article describes try/finally as a hack to get the effect of defer, but it looks to me like it's the other way around? Try/finally is more traditional, in one form or another.
It's also more exception-safe when you have more than one throwing call in the try block.
Earlier quoted context omitted.
What if you forget to use that and just use let or const? It is better than plain try-finally or defer because you don't have to remember how to dispose of the resources but in terms of remember to dispose of the resource at all, I don't think that is all that different from Python's with or Java's try-with-resources. You can just forget to use using, with, try-with-resources. There isn't any way to forget to drop a…
Yes, but you also have this problem with `defer`.
Earlier quoted context omitted.
If the idea of computers is that they remember stuff for you and do stuff for you, then both try/finally and defer seem like hacks to work around not having RAII like e.g. Rust or C++ where resources are closed/disposed of/deallocated automatically. Try X finally dispose of all resources. X, defer clean up X. Or how about just X and cleanup is done automatically, with the author of the resources deciding what is need…
it's mesmerizing that the fantastic ergonomics of RAII have not propagated to other languages. It's way easier to use, much clear, less typing, more predictable runtime behavior. RAII... terrible name, great concept!
Traditionally langages with simpler runtimes simply used destructors for this, refcounting made it deterministic (modulo the old reference leak), but more advanced garbage collection schemes made that stop working.
Article describes try/finally as a hack to get the effect of defer, but it looks to me like it's the other way around? Try/finally is more traditional, in one form or another.
Would call stack/source map reasonably work with this?
$ bat 2.ts
───────────────
1 │ function one() {
2 │ let x = 1;
3 │ defer (() => { throw new Error("thrown from one!"); })()
4 │ x = 2;
5 │ }
6 │ one();
─────┴─────────
$ node 2.js
~/healeycodes-typescript-go/2.js:29
throw _errors_1[0];
^
Error: thrown from one!
at _callee_1 (/Users/andrew/Documents/GitHub/healeycodes-typescript-go/2.js:9:46)
at /Users/andrew/Documents/GitHub/healeycodes-typescript-go/2.js:10:33
at one (/Users/andrew/Documents/GitHub/healeycodes-typescript-go/2.js:22:31)
at Object. (/Users/andrew/Documents/GitHub/healeycodes-typescript-go/2.js:34:1)
at Module._compile (node:internal/modules/cjs/loader:1830:14)
at Object..js (node:internal/modules/cjs/loader:1961:10)
at Module.load (node:internal/modules/cjs/loader:1553:32)
at Module._load (node:internal/modules/cjs/loader:1355:12)
at wrapModuleLoad (node:internal/modules/cjs/loader:255:19)
at Module.executeUserEntryPoint [as runMain (node:internal/modules/run_main:154:5)
Node.js v24.15.0