3 ms·

> What compiler failure? Pick something. I don't care. Let's say failure for reasons of having no return statement in a function that declares itself to return

> What compiler failure? Pick something. I don't care. Let's say failure for reasons of having no return statement in a function that declares itself to return something. If you could flip a switch to see that code still compile somehow, knowing that the program is not correct, would you deploy it to production? > Go literally does not warn you until it hits the error at runtime for these exceptions. True, but only because the Go compiler isn't very smart. It trades having a simpler compiler for allowing some programmer faults to not be caught until runtime. But if there was such a thing as an ideal Go compiler, those exceptions would be caught at compile time. When it comes to exceptions, the fault is in the code itself, unlike errors where the fault is external to the program. Theoretically, those faults could be found before runtime. But it is a really hard problem to solve; hence why we accept exceptions as a practical tradeoff. We are just engineers at the end of the day.

quaunaut 3y ago
Except we could just treat them the same, and we could have a type system that makes that possible. Multiple languages before Go had a solution to this, that could've been used. Or, it could've written said sufficiently advanced compiler itself. Instead, they didn't. And we all suffer for it.
- randomdata 3y ago
  We could, but we learned from those attempts that came before Go that it is a bad idea. There is good reason why the languages newer than Go, including Rust, also keep a clear division between errors and exceptions. We already lived through the suffering. The new age of recognizing that exceptions and errors are in no way the same thing and should not be treated as such is a breath of fresh air.
  - groestl 3y ago
    > why the languages newer than Go, including Rust, also keep a clear division between errors and exceptions. There are also languages older than Go that make this distinction. Java for example. Like Rust (and in contrast to Go) they even have syntax for convenience, and the compiler checks that you handle them. You know how you can immediately spot old Java APIs and code? The one that was designed and written while we lived through the suffering? Whenever you encounter checked exceptions. Turns out there is no (or even negative) value in this rather arbitrary separation.
    - randomdata 3y ago
      Obviously every language can make that distinction. As far as the computer is concerned, errors are no different than email addresses and phone numbers, which are equally representable in every language. Even Java could have errors. With respect to the bits and bites, exceptions only stand out in that they carry stack trace information. That is useless for email address, phone numbers, and errors. A hard drive crash doesn't happen at line 32. It happens in the hard drive! But knowing that the fault lies at line 32 is very useful for resolving programmer mistakes. If you get a divide by zero exception at line 32, then you know that you missed a conditional on line 31. Exceptions are compiler errors that the compiler missed. By convention, Java does not acknowledge the existence of errors. It believes that every fault is a programmer mistake, with some programming mistakes needing to be explicitly checked for some reason. Which, of course, questions why you let programmer mistakes ship given that you know that there is a programmer mistake in your code? That doesn't make any sense. But as you point out, everyone these days agrees that idea was nonsensical.
      - groestl 3y ago
        > Java does not acknowledge the existence of errors. It believes that every fault is a programmer mistake Oh, you're distracted by the stack traces, of which you have a strong opinion, but it's exactly the opposite. What modern Java code does is (in the wake of Exceptional C++) it accepts failure as a given. It does not matter what's the _cause_ of a failure, be it the programmer's fault or failure of a pre-dependend system. It's the job of the dev to ensure that the process can never leave a defined state. And the way to do that is to write exception safe code, and not to handle-all-errors (TM).
        randomdata 3y ago
        > Oh, you're distracted by the stack traces Well, there is nothing else. Capturing the stack in a value along with some metadata is all that there is to an exception. Were you wanting me to say something about the weather? > It does not matter what's the _cause_ of a failure Except when it does. Let's say the failure is that the user is a child when your requirements demand that they are an adult. age < 18, which produces an error state, doesn't create, let alone raise an exception. Hilariously, you have to resort to Go-style error handling: if (age < 18) { // Do something with the failure. // Are we writing Go now? I thought this was Java. } > It's the job of the dev to ensure that the process can never leave a defined state. If the developer ensures that the process doesn't leave a defined state, then this discussion is moot. You will never encounter an exception. Exceptions are raised when the process enters an undefined state.
- groestl 3y ago
  > it could've written said sufficiently advanced compiler itself. They couldn't, because that compiler would need to solve the halting problem.
  - randomdata 3y ago
    They could. The halting problem is solved (well, worked around) by adding a complete type system, which the compiler is free to implement. But with respect to this discussion the compiler does not need to solve the halting problem. It can assume the program always halts. It makes no difference if the program actually halts or not.

quaunaut 3y ago

Except we could just treat them the same, and we could have a type system that makes that possible. Multiple languages before Go had a solution to this, that could've been used. Or, it could've written said sufficiently advanced compiler itself. Instead, they didn't. And we all suffer for it.

randomdata 3y ago
We could, but we learned from those attempts that came before Go that it is a bad idea. There is good reason why the languages newer than Go, including Rust, also keep a clear division between errors and exceptions. We already lived through the suffering. The new age of recognizing that exceptions and errors are in no way the same thing and should not be treated as such is a breath of fresh air.
- groestl 3y ago
  > why the languages newer than Go, including Rust, also keep a clear division between errors and exceptions. There are also languages older than Go that make this distinction. Java for example. Like Rust (and in contrast to Go) they even have syntax for convenience, and the compiler checks that you handle them. You know how you can immediately spot old Java APIs and code? The one that was designed and written while we lived through the suffering? Whenever you encounter checked exceptions. Turns out there is no (or even negative) value in this rather arbitrary separation.
  - randomdata 3y ago
    Obviously every language can make that distinction. As far as the computer is concerned, errors are no different than email addresses and phone numbers, which are equally representable in every language. Even Java could have errors. With respect to the bits and bites, exceptions only stand out in that they carry stack trace information. That is useless for email address, phone numbers, and errors. A hard drive crash doesn't happen at line 32. It happens in the hard drive! But knowing that the fault lies at line 32 is very useful for resolving programmer mistakes. If you get a divide by zero exception at line 32, then you know that you missed a conditional on line 31. Exceptions are compiler errors that the compiler missed. By convention, Java does not acknowledge the existence of errors. It believes that every fault is a programmer mistake, with some programming mistakes needing to be explicitly checked for some reason. Which, of course, questions why you let programmer mistakes ship given that you know that there is a programmer mistake in your code? That doesn't make any sense. But as you point out, everyone these days agrees that idea was nonsensical.
    - groestl 3y ago
      > Java does not acknowledge the existence of errors. It believes that every fault is a programmer mistake Oh, you're distracted by the stack traces, of which you have a strong opinion, but it's exactly the opposite. What modern Java code does is (in the wake of Exceptional C++) it accepts failure as a given. It does not matter what's the _cause_ of a failure, be it the programmer's fault or failure of a pre-dependend system. It's the job of the dev to ensure that the process can never leave a defined state. And the way to do that is to write exception safe code, and not to handle-all-errors (TM).
      - randomdata 3y ago
        > Oh, you're distracted by the stack traces Well, there is nothing else. Capturing the stack in a value along with some metadata is all that there is to an exception. Were you wanting me to say something about the weather? > It does not matter what's the _cause_ of a failure Except when it does. Let's say the failure is that the user is a child when your requirements demand that they are an adult. age < 18, which produces an error state, doesn't create, let alone raise an exception. Hilariously, you have to resort to Go-style error handling: if (age < 18) { // Do something with the failure. // Are we writing Go now? I thought this was Java. } > It's the job of the dev to ensure that the process can never leave a defined state. If the developer ensures that the process doesn't leave a defined state, then this discussion is moot. You will never encounter an exception. Exceptions are raised when the process enters an undefined state.
groestl 3y ago
> it could've written said sufficiently advanced compiler itself. They couldn't, because that compiler would need to solve the halting problem.
- randomdata 3y ago
  They could. The halting problem is solved (well, worked around) by adding a complete type system, which the compiler is free to implement. But with respect to this discussion the compiler does not need to solve the halting problem. It can assume the program always halts. It makes no difference if the program actually halts or not.