431
average c++ dev (programming.dev)
submitted 1 year ago by to c/programmer_humor@programming.dev
110 comments fedilink hide all child comments
 

I don't think that casting a range of bits as some other arbitrary type "is a bug nobody sees coming".

C++ compilers also warn you that this is likely an issue and will fail to compile if configured to do so. But it will let you do it if you really want to.

That's why I love C++

a screenshot from linkedin reading "I don't think that casting a range of bits as some other arbitrary type "is a bug nobody sees coming". C++ compilers also warn you that this is likely an issue and will fail to compile if configured to do so. But it will *let you do it* if you really want to. That's why I love C++"
you are viewing a single comment's thread
view the rest of the comments
[–] 5 points 1 year ago (2 children)

For this example, I feel that it is actually fairly ergonomic in languages that have an Option type (like Rust), which can either be Some value or no value (None), and don't normally have null as a concept. It normalizes explicitly dealing with the None instead of having null or hidden empty strings and such.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 1 year ago (1 child)

    I just prefer an exception be thrown if I forget to set something so it's likely to happen as soon as I test it and will be easy to find where I missed something.

    I don't think a language is going to prevent someone from making a human error when writing code, but it should make it easy to diagnose and fix it when it happens. If you call it null, "", empty, None, undefined or anything else, it doesn't change the fact that sometimes the person writing the code just forgot something.

    Abstracting away from the problem just makes it more fuzzy on where I just forgot a line of code somewhere. Throwing an exception means I know immediately that I missed something, and also the part of the code where I made the mistake. Trying to eliminate the exception doesn't actually solve the problem, it just hides the problem and makes it more difficult to track down when someone eventually notices something wasn't populated.

    Sometimes you want the program to fail, and fail fast (while testing) and in a very obvious way. Trying to make the language more "reliable" instead of having the reliability of the software be the responsibility of the developer can mean the software always "works", but it doesn't actually do what it's supposed to do.

    Is the software really working if it never throws an exception but doesn't actually do what it's supposed to do?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 1 year ago

    It is fair to have a preference for exceptions. It sounds like there may be a misunderstanding on how Option works.

    Have you used languages that didn't have null and had Option instead? If we look at Rust, you can't forget not to check it: it is impossible to get the Some of an Option without dealing with the None. You can't forget this. You can mess up in a lot of other ways, but you explicitly have to decide how to handle that potential None case.

    If you want it to fail fast and obvious, there are ways to do this. For example you, you can use the unwrap() method to get the contained Some value or panic if it is None, expect() to do the same but with a custom panic message, the ? operator to get the contained Some value or return the function with None, etc. Tangentially, these also work for Result, which can be Ok or Err.

    It is pretty common to use these methods in places where you always want to fail somewhere that you don't expect should have a None or where you don't want your code to deal with the consequences of something unexpected. You have decided this and live with the consequences, instead of it implicitly happening/you forgetting to deal with it.

  • permalink
  • fedilink
  • source
  • parent