Explicit Error Propagation (Zig-Inspired)

[sanathusk]

Summary

This proposal suggests introducing explicit error handling primitives inspired by Zig and Swift. It aims to move Dart towards safer, checked exception handling without breaking existing unchecked exception flows, using the familiar try keyword as an expression.

1. Motivation

Current Dart exceptions are unchecked; a caller has no syntactic indicator that a function might throw. This leads to hidden runtime failures and "catch-all" debugging. This proposal adds visible fallibility to function signatures and call sites, making control flow explicit.

2. Proposed Syntax

Phase 1: The Fallible Marker (!)

We introduce a syntactic sugar ! to return types.

• Current: Future<User> fetchUser() (Might throw, might return User).
• Proposed: Future<User>! fetchUser() (Explicitly returns User OR Error).

The ! acts as a compile-time flag. It forces the caller to acknowledge the potential failure.

Phase 2: Propagation (try Expression)

We overload the try keyword to act as a prefix operator when handling ! types.

Usage Rules:

1. Propagation (Early Return): When used before a function call, try attempts to unwrap the value. If the function fails, it immediately returns the error to the caller (similar to Zig).
2. Visual Clarity: It distinguishes "dangerous" calls from standard calls at a glance.

3. Code Examples

A. Defining a Fallible Function

// The '!' indicates this function returns a String or throws an error
String! readFile(String path) {
  if (!exists(path)) {
    throw FileNotFoundException(path); // This becomes the error value
  }
  return "File Content";
}

B. Propagation (The try Keyword)

In this scenario, we do not want to handle the error locally; we want to pass it up the stack automatically.

String! getConfig() {
  // If readFile fails, the error is immediately returned from getConfig.
  // Execution stops here. The 'try' keyword makes the exit point visible.
  var content = try readFile("config.txt");
  
  return parse(content);
}

C. Handling Errors

To actually handle the error, we use the standard try/catch block, but the inner call remains explicit.

void main() {
  try {
    // We use 'try' here to acknowledge the fallible call.
    // If it fails, it jumps to the catch block as usual.
    var config = try getConfig();
    print("Config loaded: $config");
  } catch (e) {
    // The compiler knows 'getConfig' throws, so this catch is strictly typed.
    print("Failed to load config: $e");
  }
}

4. Backward Compatibility

To ensure non-breaking changes:

1. Opt-in: Functions without ! remain "Unchecked" (standard Dart behavior).
2. Gradual Adoption: The analyzer can suggest converting Type to Type! if it detects throwing behavior.
3. No Syntax Conflicts: try is currently only valid before a { block. Using it as a prefix to an expression (try func()) is syntactically unambiguous to the parser.

[isoos]

A drive-by comment: wouldn't this be better to implement as an annotation + a linter check?

[gochev]

Isn't throws in the method signature like in Java far better then a !

At least in Java you know the types of exception the method might throw

[lrhn]

This can work.

It's a marker on covariant types, which says that code receiving the result must acknowledge a potential thrown value.

It's in the type system, so it needs to work with other types. Probably int is a subtype of int!.
You can use a function that doesn't throw where a function that potentially throws.
(So the new top type is Object?!. Maybe using ! isn't that great a syntax.)

The type system needs a way to recognize which types this can apply to. It makes no sense to put a ! on a parameter type.
On the other hand, it must be possible to use it on type parameters, because there is a difference between Future<int!> and Future<int>!.
So maybe it needs variance annotations on type parameters, so it can only be applied to arguments of covariant parameters.
Or it just only works with parameters that have a ! type as bound, and the default bound will still be Object?. It's opt-in every step of the way.

Any expression with a !-type must be prefixed by try. Then either the expression must be inside a try/catch or inside a function with a !-typed return type. (The try in front feels redundant if its inside another class try/catch.)

There is no guarantee that the try/catch will catch the intended exception type, but you can't forget to handle it.

Not sure a change to the type system as pervasive as a new top type of worth the benefit.
It'll be a lot of syntactic overhead for code that builds on top of I/O, which can usually always throw something.

[FMorschel]

Though, checked exceptions would be easily converted to unchecked ones with a simple wrapper function--which will then be used everywhere, making the proposal probably kinda pointless.

But that is a choice the caller must do. Imagine Future calls today with unawaited. That is basically the same thing. There are obviously cases where that is useful, but not everyone would chose that.

[MarvinHannott]

Honestly, I'm a bit confused by example C. In the previous examples, the try keyword marks error propagation, but within the try-catch block it suddenly doesn't? Wouldn't it make more sense that you don't need to call a function with try inside a try-catch block? Actually, that would open a rather interesting use case: throwing exceptions from inside throw-catch without immediately catching it. That would seriously improve code ergonomics at times.

On the other hand, how do you actually ensure that the thrown exception type gets actually cought? Your example presents an "catch all" scenario, but what if it isn't?

[MarvinHannott]

Though, checked exceptions would be easily converted to unchecked ones with a simple wrapper function--which will then be used everywhere, making the proposal probably kinda pointless.

But that is a choice the caller must do. Imagine Future calls today with unawaited. That is basically the same thing. There are obviously cases where that is useful, but not everyone would chose that.

Yeah, I probably misunderstood the proposal 😀

[hydro63]

Isn't throws in the method signature like in Java far better then a !

At least in Java you know the types of exception the method might throw

AFAIK, it would be a hell to work with in Dart. Since in Dart you can throw basically anything (eg. Error, Exception, String, even int), it makes typing exceptions really hard. And even if you yourself use proper Exception objects instead of pure String, you don't have a guarantee that the libraries you are using are also as strict and clean with their exception handling. Now, imagine you are using an unchecked library function (which can actually still throw), but you don't want to handle possible exceptions at the call site, and instead want to propagate it up the call stack, and let the caller handle it.

In such a setup, you would have to list all the different things that the library can throw, without ever being certain that you've listed everything he could possibly be throwing. Either you do that, or you just give up and type it as an Object, making such a feature pointless.

Basically, you can't just retrofit a new kind of type information on top of program that doesn't inherently provide it.

ps: i have made a similar kind of typed Exceptions proposal to typescript, and they've refused it with a similar argumentation.