| ▲ | quotemstr a day ago |
| No, because you end up with a function coloring problem that way. A function that returns something other than Result has to either call only infallible code or panic on error, and since something can go wrong in most code, the whole codebase converges as time goes to infinity on having Result everywhere. Yeah, yeah, you can say it's explicit and you can handle it how you want and so on, but the overall effect is just a noisy spelling of exceptions with more runtime overhead and fewer features. |
|
| ▲ | dwattttt a day ago | parent | next [-] |
| I very much care about whether a function can fail or not, and I encourage all the function colouring needed to convey that. |
| |
| ▲ | funcDropShadow a day ago | parent [-] | | As almost always, we programmers / software developers / engineers, forget to state our assumptions. In closed-world, system-software, or low-level software you want to have your kind of knowledge about everything you call. Even more: can it block? In open-world, business-software, or high-level software it is often impossible or impractical to know all the ways in which a function or method can fail. What you need then, is a broad classification of errors or exception in the following two dimensions: 1. transient or permanent, 2. domain or technical. Those four categories are most of the time enough to know whether to return a 4xx or 5xx error or to retry in a moment or to write something into a log where a human will find it. Here, unchecked exceptions are hugely beneficial. Coincidentally, that is the domain of most Java software. Of course, these two groups of software systems are not distinct, there is a grey area in the middle. | | |
| ▲ | maleldil 4 hours ago | parent [-] | | Monadic error handling (such as Rust's) is a good compromise because it allows you to handle errors precisely when you want to _and_ bubble them up with minor boilerplate when you don't. You can even add context without unwrapping the whole thing. That's why it's often considered one of the better approaches: it has both the "errors as values" benefits (encoding errors in the type system) and avoids many of its problems (verbosity when you just want to bubble up). |
|
|
|
| ▲ | Too a day ago | parent | prev | next [-] |
| I think your conclusion is on the right track. Syntax sugar propagating results is in a way equivalent to exceptions. What you are missing it isn’t just equivalent to ordinary exceptions. It’s more equivalent to checked exceptions. A very powerful concept, that unfortunately got a bad rap, because the most widespread implementation of it (Java) was unreasonably verbose to use in practice. You might claim Rust is still too verbose and I don’t disagree with that, it’s a big improvement from Java at least, while at the same time providing even more safety nets. |
| |
| ▲ | jll29 21 hours ago | parent [-] | | Yes, Java is too verbose, but Kotlins cleaned up much of that boilerplate and runs on the same VM. I'd be curious to see examples for where you think Rust is still to verbose. | | |
| ▲ | maleldil 4 hours ago | parent [-] | | You misunderstood. They meant that Java's checked exceptions are very verbose and that Rust's approach to errors is similar. While Rust's approach is less verbose, it's still more verbose than "regular" (unchecked exceptions). Kotlin isn't relevant here because all exceptions are unchecked. |
|
|
|
| ▲ | high_na_euv 6 hours ago | parent | prev | next [-] |
| "Function coloring problem" Function coloring isnt a problem, it is just approach |
|
| ▲ | sunshowers a day ago | parent | prev | next [-] |
| Function "coloring" is good! It's not a problem here and it's overblown as a problem in general. If something fails recoverably then it should be indicated as such. |
|
| ▲ | pyrale a day ago | parent | prev [-] |
| > A function that returns something other than Result has to either call only infallible code or panic on error ...Or solve the problem. A library function that can be a source of issues and can't fix these issues locally should simply not be returning something that is not a result in that paradigm. > since something can go wrong in most code That is not my experience. Separating e.g. business logic which can be described cleanly and e.g. API calls which don't is a clear improvement of a codebase. > the whole codebase converges as time goes to infinity on having Result everywhere. As I said previously, it is pretty easy to pipe a result value into a function that requires a non-result as input. This means your pure functions don't need to be colored. |
| |
| ▲ | quotemstr a day ago | parent [-] | | > Or solve the problem. A library function that can be a source of issues and can't fix these issues locally should simply not be returning something that is not a result in that paradigm. People "solve" this problem by swallowing errors (if you're lucky, logging them) or by just panicking. It's the same problem that checked exceptions in Java have: the error type being part of the signature constrains implementation flexibility. | | |
| ▲ | ViewTrick1002 a day ago | parent [-] | | In my experience an unwrap, expect or panicking function is a direct comment in code review and won’t be merged without a reason explaining why panicking is acceptable. |
|
|
