5 ms·

> Stack overflow? Exception. The minimum available stack space is a known quantity. Exceeding it means you made a mistake. > Out of memory? Error. The availa

> Stack overflow? Exception. The minimum available stack space is a known quantity. Exceeding it means you made a mistake. > Out of memory? Error. The available heap is typically not predictable. Your allocation function should provide an error state; and, indeed, malloc and friends do. > And don't tell me, that's not possible It is perfectly possible. Probably not a good idea, though, as you have proven that your code is fundamentally broken. Would you put your code in production if there was a way to ignore compiler failure?

quaunaut 3y ago
> Would you put your code in production if there was a way to ignore compiler failure? What compiler failure? Go literally does not warn you until it hits the error at runtime for these exceptions.
- randomdata 3y ago
  > 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
> The minimum available stack space is a known quantity. It is. Tracking and erroring out on it to avoid the exception means replicating your runtime environment's mechanism for tracking and erroring out on stack overflow (system in a system / inner platform anti-pattern). Your runtime environment's implementors know that, so it's unlikely you'll find the APIs necessary to avoid an exception (i.e. a maxRecursion param and equivalent error result). > Exceeding it means you made a mistake. No, it can be just a part of processing a request. Depending on the particular runtime environment, it does not have any impact on other parts of the process.
- randomdata 3y ago
  > so it's unlikely you'll find the APIs necessary to avoid an exception Lacking a needed API is programmer error. Better programming can avoid that kind of exception. A hypothetical, sufficient smart compiler could fail at compile time, warning you are missing code to handle certain states in the absence of such an API. To reiterate, exceptions are faults which come as a result of incorrect programs. Errors are faults which come as a result of external conditions. A program that overflows the stack is an incorrect program. The stack size is known in advance. If it is overflown, a programmer didn't do proper accounting and due diligence.
  - groestl 3y ago
    > Lacking a needed API is programmer error. Whoa, easy there. We're talking about standard libraries, and the designers of those are not complete morons. The API is lacking because the runtime environment already provides a safe and defined environment for the observed behavior. It just happens to not fit your mental model, which I find too strict and off wrt reality on one hand, and infeasible on the other (Gödel wants to have a talk with you).
    - randomdata 3y ago
      Don't let perfect be the enemy of good. It is quite pragmatic to make such an error. We're ultimately talking about engineering here. Engineering is all about picking your battles and accepting tradeoffs. You go into it knowing that you will have to settle on making some mistakes. Creating an ideal world is infeasible. Indeed, it is your mental model that is too strict. To err is fine. To err is human!

quaunaut 3y ago

> Would you put your code in production if there was a way to ignore compiler failure? What compiler failure? Go literally does not warn you until it hits the error at runtime for these exceptions.

randomdata 3y ago
> 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

> The minimum available stack space is a known quantity. It is. Tracking and erroring out on it to avoid the exception means replicating your runtime environment's mechanism for tracking and erroring out on stack overflow (system in a system / inner platform anti-pattern). Your runtime environment's implementors know that, so it's unlikely you'll find the APIs necessary to avoid an exception (i.e. a maxRecursion param and equivalent error result). > Exceeding it means you made a mistake. No, it can be just a part of processing a request. Depending on the particular runtime environment, it does not have any impact on other parts of the process.

randomdata 3y ago
> so it's unlikely you'll find the APIs necessary to avoid an exception Lacking a needed API is programmer error. Better programming can avoid that kind of exception. A hypothetical, sufficient smart compiler could fail at compile time, warning you are missing code to handle certain states in the absence of such an API. To reiterate, exceptions are faults which come as a result of incorrect programs. Errors are faults which come as a result of external conditions. A program that overflows the stack is an incorrect program. The stack size is known in advance. If it is overflown, a programmer didn't do proper accounting and due diligence.
- groestl 3y ago
  > Lacking a needed API is programmer error. Whoa, easy there. We're talking about standard libraries, and the designers of those are not complete morons. The API is lacking because the runtime environment already provides a safe and defined environment for the observed behavior. It just happens to not fit your mental model, which I find too strict and off wrt reality on one hand, and infeasible on the other (Gödel wants to have a talk with you).
  - randomdata 3y ago
    Don't let perfect be the enemy of good. It is quite pragmatic to make such an error. We're ultimately talking about engineering here. Engineering is all about picking your battles and accepting tradeoffs. You go into it knowing that you will have to settle on making some mistakes. Creating an ideal world is infeasible. Indeed, it is your mental model that is too strict. To err is fine. To err is human!