this post was submitted on 29 Dec 2025
116 points (98.3% liked)

Programming

24107 readers
424 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] Undertaker@feddit.org -2 points 1 day ago (4 children)

Some knowledge about compiler was interesting. The advise to use combined return types (for errors and value) instead of exceptions is ridiculous. Some other points are weird as well. Changing language to avoid null...

Depending on the language exceptions are used in many different ways. Some use it liberally for all kinds of error handling.

A good feature of Exceptions is you can throw them all the way up the stack and handle them there, giving you loose coupling between the code that calls the dangerous code and the one that catches it.

Exceptions have a big runtime overhead, so using them for normal control flow and error handling can be a bit meh.

Using return types can be great, if the language has good support for. For example swift enums are nice for this.

enum ResultError  {
  case noAnswer;
  case couldNotAsk;
  case timeOut
}

enum Result {
  case answer: String;
  case error: ResultError
}

func ask(){
  let myResult = askQuestion(“Are return types useful?”);
  switch myResult {
    case answer: 
      print(answer);
    case error:
       handleError(error);
  }
}

func handleError(error: ResultError) {
  switch ResultError {
    case noAnswer:
      print(“Received no answer”);
    case couldNot:
      …
  }

}

Using enums and switch means the compiler ensures you handle all errors in a place you expect.

[–] douglasg14b@lemmy.world 24 points 1 day ago (1 children)

Combined return types are wonderful and make for, generally, better engineered software.

Exceptions still have their place, for exceptional circumstances, but the grand majority of errors should not be exceptions.

[–] theneverfox@pawb.social 2 points 21 hours ago
[–] expr@programming.dev 4 points 19 hours ago

https://en.wikipedia.org/wiki/Algebraic_data_type

Some reading material for you. Sum types allow for proper, compiler-enforced error handling and optionality rather than the unprincipled free for all that is exceptions and nullability.

Tony Hoare, the person that originally introduced nulls to the programming world, is oft-quoted as calling nulls the "billion dollar mistake". Here's the talk: https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/.

[–] Michal@programming.dev 3 points 23 hours ago (1 children)

Combined return types is a Rust feature.

I recently started learning Rust, and would prefer exceptions. Even Java checked exceptions aren't too bad to work with. Rust approach is Ok though and ir has a purpose.

[–] setsubyou@lemmy.world 3 points 15 hours ago (1 children)

In Rust you’re kind of stuck with it, but at the end of the day combined return types are just syntactic sugar for something a lot of languages can do. Even in plain old C there’s a pattern where you pass pointers to your return and/or error variables. In many languages you can return structs or similar. In some I’d argue it looks nicer than having to write Result<>, e.g. in Python or in Swift you can just return a tuple by putting things in parentheses. (Of course you can also still use something more explicit too. But if every function returned (result, error) by default and every call was like result, error = fn(), I don’t think it’d be necessary.)

However I don’t really know of any language where people prefer to use this over exceptions if exceptions are available. Even in C some people used to use setjmp/longjmp in macros to implement exceptions. Exceptions have their problems but people seem to overwhelmingly be in favor of them.

Personally I like exceptions in languages that have some kind of built-in “finally” for functions. For example defer in Swift. You can have proper error handling for a lot less typing in many cases because passing through exceptions is fine if your defer blocks handle the cleanup. And if you do want to handle an exception, Swift also has optionals, and a try? that transparently converts a return value into an optional that’s nil when an exception was thrown, and a coalescing operator ??, which means you can catch exceptions and provide a default value on one line, instead of a 4-5 line try..catch/except block or an error checking conditional for every call.

[–] Michal@programming.dev 2 points 14 hours ago (1 children)

Interesting that you brought up finally. I was learning Rust the last two days and didn't realise it was missing. There may be some other way of handling it.

[–] setsubyou@lemmy.world 2 points 10 hours ago

scopeguard would be one way to get defer in Rust