# arthurfiorette/proposal-try-operator

A proposal to bring ergonomic, inline error handling to JavaScript through a new try operator that always returns a Result.

Repository: https://github.com/arthurfiorette/proposal-try-operator
Canonical: https://ross.abutalabs.com/products/proposal-try-operator
Homepage: https://arthur.run/proposal-try-operator/
License: MIT
License Family: permissive
Topics: catch, effect, error, proposal, result, safe, symbol, tc39, try, tuple
Last push: 2026-04-02T01:36:15+00:00

## Health v2 (maintenance only)
Score: 57/100 (v2, computed 2026-09-03T02:20:16.233290+00:00)
- activity 75, release rhythm 35, longevity 53
- inputs: {"age_days": 751, "days_push": 154, "days_rel": null, "gap_med": null, "n_releases_24m": 0}
- flags: no_releases
- formula: round(0.45*activity + 0.35*rhythm + 0.20*longevity); archived -> min(score, 10)

## Adoption (not part of the score)
Stars 2036, forks 24 (observed 2026-08-28T04:06:08.029070+00:00)

## What it is
A Stage 0 TC39 proposal to add an ergonomic inline `try <expression>` operator to JavaScript that catches exceptions and returns a Result value instead of throwing. The repository contains the specification draft, design rationale, and a reference `Result` class implementation published to NPM as `try`.

## Use cases
- handle errors inline without try/catch blocks in javascript
- use a result pattern instead of exceptions in js
- convert thrown errors into values in javascript
- follow the status of a tc39 try operator proposal
- try a result class for safer async error handling
- avoid nested try catch blocks when parsing or fetching

## When to choose
- you want to experiment today with try-operator ergonomics via the npm `try` Result implementation
- you are researching or contributing to ECMAScript language design around error handling
- you prefer Go/Rust-style Result values over exception-based control flow in JavaScript

## When to avoid
- you need a shipped, standardized language feature - this is a Stage 0 proposal that may never reach ECMAScript
- you need type-safe typed errors, which the proposal explicitly does not aim to solve
- you need a production error-handling library with mature ecosystem support rather than a proposal reference implementation

## Facets
- artifact type: learning-resource
- maturity: active
- function: error-handling, programming-language, sdk
- domain: programming-languages, developer-tools, apis
- platform: browser, cross-platform
- tags: tc39-proposal, ecmascript, result-pattern, try-operator, error-handling, specification, stage-0, nodejs, javascript

## Member repositories
- arthurfiorette/proposal-try-operator (main) score 57

## Provenance
- Observed fields: from GitHub, fetched 2026-08-28T04:06:08.029070+00:00.
- Health v2: computed from the inputs above; adoption is never an input.
- Inferred fields (summary, facets, guidance): AI-extracted, prompt v1, taxonomy v1, on 2026-08-30T02:59:19.239849+00:00, confidence not recorded.
  - readme: https://github.com/arthurfiorette/proposal-try-operator (fetched 2026-08-28T04:06:08.029070+00:00, sha d2e81c9d906c)
  - homepage: https://arthur.run/proposal-try-operator/ (fetched 2026-08-29T10:39:10.438717+00:00, sha b758e8ee5a75)
- Data as of 2026-08-30T08:39:29.467469+00:00.
