code

Author: arthurfiorette

README.md

@@ -53,80 +53,111 @@ Only the `catch (error) {}` block represents actual control flow, while no progr
 
 <!-- Credits to https://x.com/LeaVerou/status/1819381809773216099 :) -->
 
-The `try {}` block is often redundant, as its scoping lacks meaningful conceptual significance. It generally acts more as a code annotation than a genuine control flow construct. Unlike true control flow blocks, no program state exists that requires being confined to a `try {}` block.
+The `try {}` block often feels redundant because its scoping lacks meaningful conceptual significance. Rather than serving as an essential control flow construct, it mostly acts as a code annotation. Unlike loops or conditionals, a `try {}` block doesn’t encapsulate any distinct program state that requires isolation.
 
-Conversely, the `catch {}` block **is** genuine control flow, making its scoping relevant and meaningful. According to Oxford Languages, an exception is defined as:
+On the other hand, the `catch {}` block **is** genuine control flow, making its scoping relevant. According to Oxford Languages, an exception is defined as:
 
 > a person or thing that is excluded from a general statement or does not follow a rule.
 
-Since `catch` handles exceptions, it is logical to encapsulate exception-handling logic in a block to exclude it from the general program flow.
+Since `catch` is explicitly handling exceptions, it makes sense to encapsulate exception-handling logic in a block that separates it from the normal program flow.
 
-The pseudocode below illustrates the lack of value in nesting the success path within a code block:
+<br />
+
+Consider a simple function like this:
 
 ```js
-async function handle(request, reply) {
-  try {
-    const userInfo = await cache.getUserInfo(request.id)
+function getPostInfo(session, postSlug, cache, db) {
+  const user = cache.getUser(session.userId)
 
-    try {
-      const posts = await db.getPosts(userInfo.authorId)
+  const post = db.selectPost(postSlug, user)
+  const comments = db.selectComments(post.id, user)
+
+  return { post, comments }
+}
+```
 
-      let comments
+<br />
+
+But **production code is rarely this clean**. Error handling quickly forces a messier structure:
+
+```js
+function getPostInfo(session, postSlug, cache, db) {
+  let user
 
-      // Variables used after error handling must be declared outside the block
-      try {
-        comments = await db.getComments(posts.map((post) => post.id))
-      } catch (error) {
-        logger.error(error, "Posts without comments not implemented yet")
-        return reply.status(500).send({ error: "Could not get comments" })
-      }
+  // Requires a dedicated error handler
+  try {
+    user = cache.getUser(session.userId)
+  } catch (error) {
+    otel.capture(error, Operations.GET_SELF)
+    session.logout()
+    throw new Error("Invalid session")
+  }
 
-      // Do something with comments before returning
-      return reply.send({ userInfo, posts, comments })
+  // No recovery if selectPost fails
+  try {
+    const post = db.selectPost(postSlug, user)
+
+    let comments = []
+
+    // The post must still be returned even if fetching comments fails
+    try {
+      comments = db.selectComments(post.id, user)
     } catch (error) {
-      logger.error(error, "Anonymous user behavior not implemented yet")
-      return reply.status(500).send({ error: "Could not get posts" })
+      otel.capture(error, Operations.JOIN_POST_COMMENTS)
     }
   } catch (error) {
-    logger.error(error, "Maybe DB is down?")
-    return reply.status(500).send({ error: "Could not get user info" })
+    otel.capture(error, Operations.GET_POST)
+    throw new Error("Could not get post")
   }
+
+  return { post, comments }
 }
 ```
 
-With the proposed `try` statement, the same function can be rewritten as:
+The `try` blocks didn't provide much value beyond introducing unnecessary nesting.
 
-```js
-async function handle(request, reply) {
-  const userInfo = try await cache.getUserInfo(request.id)
+Instead, using the proposed `try` operator simplifies the function:
 
-  if (!userInfo.ok) {
-    logger.error(userInfo.error, "Maybe DB is down?")
-    return reply.status(500).send({ error: "Could not get user info" })
+<br />
+
+```js
+function getPostInfo(session, postId, cache, db) {
+  const [userOk, userErr, user] = try cache.getUser(session.userId)
+
+  // Requires a dedicated error handler
+  if (!userOk) {
+    otel.capture(userErr, Operations.GET_SELF)
+    session.logout()
+    throw new Error("Invalid session")
   }
 
-  const posts = try await db.getPosts(userInfo.value.authorId)
+  const [postOk, postErr, post] = try db.selectPost(postId, user)
 
-  if (!posts.ok) {
-    logger.error(posts.error, "Anonymous user behavior not implemented yet")
-    return reply.status(500).send({ error: "Could not get posts" })
+  // No recovery if selectPost fails
+  if (!postOk) {
+    otel.capture(postErr, Operations.GET_POST)
+    throw new Error("Could not get post")
   }
 
-  const comments = try await db.getComments(posts.value.map((post) => post.id))
+  const [commentsOk, commentsErr, comments = []] = try db.selectComments(
+    post.id,
+    user
+  )
 
-  if (!comments.ok) {
-    logger.error(comments.error, "Posts without comments not implemented yet")
-    return reply.status(500).send({ error: "Could not get comments" })
+  // The post must still be returned even if fetching comments fails
+  if (!commentsOk) {
+    otel.capture(commentsErr, Operations.JOIN_POST_COMMENTS)
   }
 
-  // No need for reassignable variables or nested try/catch blocks
-
-  // Do something with comments before returning
-  return reply.send({ userInfo: userInfo.value, posts: posts.value, comments: comments.value })
+  return { post, comments }
 }
 ```
 
-A `try` statement provides significant flexibility and arguably results in more readable code. A `try` statement is a statement that can be used wherever a statement is expected, allowing for concise and readable error handling.
+This approach improves readability by cleanly separating the happy path from error handling.
+
+Control flow remains linear, making it easier to follow, while only the "exceptions" in execution require explicit scoping.
+
+The result is a more structured, maintainable function where failures are handled concisely without unnecessary indentation.
 
 <br />