6 ms·

> In Go or Rust, returning an error is also a “color” that spreads out to the top of the call stack. Not unless you're doing it wrong. Errors need to be handle

> In Go or Rust, returning an error is also a “color” that spreads out to the top of the call stack. Not unless you're doing it wrong. Errors need to be handled. That may, in some cases, mean handling it with another error, but that isn't adding any "color". The new error is independent of any previous error state.

littlestymaar 2y ago
You're misunderstanding: the fact that the new error is different from the original one doesn't change the fact that the function returns an error. Exactly like how async functions awaiting on a promise to create new promises doesn't change the fact that the function is an async one. Sure sometimes you can avoid propagating the error upward, but that's not the most common case and it also happens with async/await (if you don't need the result of the promise in the caller function you don't need to await and to make it a async function). In Rust the similarity is very flagrant because there are one postfix operators for both (? and .await).
- assbuttbuttass 2y ago
  > if you don't need the result of the promise in the caller function you don't need to await and to make it a async function Why call it at all, then? In Rust, futures don't run unless you poll them, so just calling an async function without polling it doesn't do anything. In contrast, for error returns it's very common to log an error but continue with some default value, or just skip processing one item and continue with the rest. There are a lot of cases where errors can be handled immediately, rather than always blindly bubbled up the call stack
  - littlestymaar 2y ago
    > Why call it at all, then? In Rust, futures don't run unless you poll them, so just calling an async function without polling it doesn't do anything. Rust is a bit special as the futures are lazy and you need to call your future with `task::spawn` if you want this to work, but it still does. And in other languages it's going to work directly without doing anything in addition to calling the async function. > In contrast, for error returns it's very common to log an error but continue with some default value, or just skip processing one item and continue with the rest. There are a lot of cases where errors can be handled immediately, rather than always blindly bubbled up the call stackm It really is use-case dependent but I don't think it's more common than letting the request run in the background without waiting for its result. In fact your log example is a funny one because as soon as you use remote logging you're going to let the request run in the background and never await it (otherwise you'd get tons of gratuitous latency).
- deleted 2y ago
  [deleted]
- randomdata 2y ago
  You're misunderstanding. async/await creates a dependence. errors do not – at least no more than any other type. Would you say your perspective on "coloring" is equally applicable to email addresses? I might buy into your idea the "?" operator colors functions. But that's something else entirely and obviously isn't what you were talking about originally as it isn't found in all of the languages originally mentioned.
  - littlestymaar 2y ago
    > async/await creates a dependence. errors do not. It does! In both case you need to "unwrap" the value, and in most case it means making the caller function async or returning the error. (As an anecdote I've done way more refactoring involving replacing T with Result<T> in entire call stacks in Rust that I've done it for async). > I might buy into your idea the "?" operator colors functions. But that's something else entirely and obviously isn't what you were talking about originally as it isn't found in all of the languages originally mentioned It's exactly the same with Java's checked exception and Go errors, as soon as you start calling a function that returns an error, you're going to write something that looks like if err != nil { return 0, err } And tada! your functions now need to add the error to it's return parameter.
    - deleted 2y ago
      [deleted]
    - randomdata 2y ago
      > It does! In both case you need to "unwrap" the value Just as you do with any value, such as an email address, returned by a function. It is curious that you avoided my question as it would help us better understand where you are trying to come from. If that is the stance you are trying to take you're not exactly wrong about there still being some sort of dependence – there is an inherit dependency created when calling a function, always - but there is not a different color of dependence found within that. You're missing the intent of "coloring" if that is what you are trying to say. async/await introduces a different type of dependence than a function would normally present, where the dependence is no longer direct. I may even agree that the "?" operator introduces a similar indirect dependence. But a function returning an email address (or error; the type of the value is immaterial) is the "natural color" of a function. If that is all you have, there isn't a secondary color. > as soon as you start calling a function that returns an error, you're going to write something that looks like Only for internet memes. You would never write production code like that for so many reasons.

littlestymaar 2y ago

You're misunderstanding: the fact that the new error is different from the original one doesn't change the fact that the function returns an error. Exactly like how async functions awaiting on a promise to create new promises doesn't change the fact that the function is an async one. Sure sometimes you can avoid propagating the error upward, but that's not the most common case and it also happens with async/await (if you don't need the result of the promise in the caller function you don't need to await and to make it a async function). In Rust the similarity is very flagrant because there are one postfix operators for both (? and .await).

assbuttbuttass 2y ago
> if you don't need the result of the promise in the caller function you don't need to await and to make it a async function Why call it at all, then? In Rust, futures don't run unless you poll them, so just calling an async function without polling it doesn't do anything. In contrast, for error returns it's very common to log an error but continue with some default value, or just skip processing one item and continue with the rest. There are a lot of cases where errors can be handled immediately, rather than always blindly bubbled up the call stack
- littlestymaar 2y ago
  > Why call it at all, then? In Rust, futures don't run unless you poll them, so just calling an async function without polling it doesn't do anything. Rust is a bit special as the futures are lazy and you need to call your future with `task::spawn` if you want this to work, but it still does. And in other languages it's going to work directly without doing anything in addition to calling the async function. > In contrast, for error returns it's very common to log an error but continue with some default value, or just skip processing one item and continue with the rest. There are a lot of cases where errors can be handled immediately, rather than always blindly bubbled up the call stackm It really is use-case dependent but I don't think it's more common than letting the request run in the background without waiting for its result. In fact your log example is a funny one because as soon as you use remote logging you're going to let the request run in the background and never await it (otherwise you'd get tons of gratuitous latency).
deleted 2y ago
[deleted]
randomdata 2y ago
You're misunderstanding. async/await creates a dependence. errors do not – at least no more than any other type. Would you say your perspective on "coloring" is equally applicable to email addresses? I might buy into your idea the "?" operator colors functions. But that's something else entirely and obviously isn't what you were talking about originally as it isn't found in all of the languages originally mentioned.
- littlestymaar 2y ago
  > async/await creates a dependence. errors do not. It does! In both case you need to "unwrap" the value, and in most case it means making the caller function async or returning the error. (As an anecdote I've done way more refactoring involving replacing T with Result<T> in entire call stacks in Rust that I've done it for async). > I might buy into your idea the "?" operator colors functions. But that's something else entirely and obviously isn't what you were talking about originally as it isn't found in all of the languages originally mentioned It's exactly the same with Java's checked exception and Go errors, as soon as you start calling a function that returns an error, you're going to write something that looks like if err != nil { return 0, err } And tada! your functions now need to add the error to it's return parameter.
  - deleted 2y ago
    [deleted]
  - randomdata 2y ago
    > It does! In both case you need to "unwrap" the value Just as you do with any value, such as an email address, returned by a function. It is curious that you avoided my question as it would help us better understand where you are trying to come from. If that is the stance you are trying to take you're not exactly wrong about there still being some sort of dependence – there is an inherit dependency created when calling a function, always - but there is not a different color of dependence found within that. You're missing the intent of "coloring" if that is what you are trying to say. async/await introduces a different type of dependence than a function would normally present, where the dependence is no longer direct. I may even agree that the "?" operator introduces a similar indirect dependence. But a function returning an email address (or error; the type of the value is immaterial) is the "natural color" of a function. If that is all you have, there isn't a secondary color. > as soon as you start calling a function that returns an error, you're going to write something that looks like Only for internet memes. You would never write production code like that for so many reasons.