undefined | Better HN

0 pointssfink4mo ago0 comments

...and you can? try-catch is usually less ergonomic than the various ways you can inspect a Result.

    try {
      data = some_sketchy_function();
    } catch (e) {
      handle the error;
    }

    result = some_sketchy_function();
    if let Err(e) = result {
      handle the error;
    }

Or better yet, compare the problematic cases where the error isn't handled:

    data = some_sketchy_function();

    data = some_sketchy_function().UNWRAP_OR_PANIC();

In the former (the try-catch version that doesn't try or catch), the lack of handling is silent. It might be fine! You might just depend on your caller using `try`. In the latter, the compiler forces you to use UNWRAP_OR_PANIC (or, in reality, just unwrap) or `data` won't be the expected type and you will quickly get a compile failure.

What I suspect you mean, because it's a better argument, is:

    try {
        sketchy_function1();
        sketchy_function2();
        sketchy_function3();
        sketchy_function4();
    } catch (e) {
        ...
    }

which is fair, although how often is it really the right thing to let all the errors from 4 independent sources flow together and then get picked apart after the fact by inspecting `e`? It's an easier life, but it's also one where subtle problems constantly creep in without the compiler having any visibility into them at all.

0 comments

Nathanba4mo ago

it's practically always the case that you use a try-catch for more than just one source / line of code. I mean except for database/network calls I don't think I even remember a single case where I ever used a try-catch just for a single line of code. The subtle problems come from errors handling via values. You check but do you check perfectly? What happens when APIs change and the underlying functions add more error cases, then you constantly have more work to do. Nonstop constant error checking that you don't care about. This is exactly where humans are terrible: Really important work that is drudgery and where if you ever mess up once, you fail in very painful ways. Exception handling solves all of this, it fits how humans should be working and it fits the underlying hardware reality as well: We are big picture, we should not be designing languages for describing logic that force us to do drudgery work constantly and care about implementation details of every single thing we call.

j / k navigate · click thread line to collapse