5 ms·

> It creates 2 disparate types of error handling They are disparate conditions. Errors happen in response to conditions that occur during the execution of the

> It creates 2 disparate types of error handling They are disparate conditions. Errors happen in response to conditions that occur during the execution of the application. Exceptions happen in response to conditions that occurred when the code was written. Very different things. It is highly unlikely that you want to handle an exception. It's the runtime equivalent of a compiler error. Do you also want to handle compiler errors so that your faulty code still compiles? Of course not, so why would you want to do the same when your coding mistakes are noticed at runtime? There are, uh, exceptions to that when it is necessary to handle exceptions, but if it you see it as routine you're doing something wrong. If you overloaded that with errors, forcing it to be routine, you'd have a nightmare on your hands (like in those other languages that have tried it).

groestl 3y ago
> Exceptions happen in response to conditions that occurred when the code was written. Huh? Stack overflow? Out of memory? > It is highly unlikely that you want to handle an exception It is very likely that I want to handle an exception. In fact, I want to handle all exceptions and keep my process and all other concurrent requests to it running. And don't tell me, that's not possible, because I've been doing that for decades. In Java that is.
- randomdata 3y ago
  > 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
    > 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!
troupo 3y ago
> Errors happen in response to conditions that occur during the execution of the application. Exceptions happen in response to conditions that occurred when the code was written. wat. You have code that ends up dividing by zero, and boom, you have an exception while the app is running. > It is highly unlikely that you want to handle an exception. You always want to handle an exception. That is how actual resilient systems are written
- troupo 3y ago
  Got downvoted. Do read Joe Armstrong's Making reliable distributed systems in the presence of software errors https://erlang.org/download/armstrong_thesis_2003.pdf https://erlang.org/download/armstrong_thesis_2003.pdf
- randomdata 3y ago
  > You have code that ends up dividing by zero, and boom, you have an exception while the app is running. Yes, and? That problem arose when the code was written. There is no reason why a program should ever find itself in a state where division by zero can occur. A simple if statement is all it takes to avoid that. If you see a divide by zero exception, the developer fucked up; having wrote an incorrect program. That's entirely different to, say, a hard drive crash causing writes to fail. Not even an ideal programmer writing an ideal piece of software completely void of all defects can avoid an error condition. > You always want to handle an exception. No. You always want to ensure that you have no exceptions in the first place. They are the runtime equivalent of compiler errors. If you encounter an exception in your software, you screwed up. There are circumstances where handling exceptions is warranted, but if you are routinely handling exceptions throughout your development, something is amiss.
  - Gibbon1 3y ago
    Once you get outside webshit you have a world where things need to be able to get the job done even in the presence of software bugs. And software bugs are just another type of failure. Some of those involve cases where failure is expensive or life threatening.

groestl 3y ago

> Exceptions happen in response to conditions that occurred when the code was written. Huh? Stack overflow? Out of memory? > It is highly unlikely that you want to handle an exception It is very likely that I want to handle an exception. In fact, I want to handle all exceptions and keep my process and all other concurrent requests to it running. And don't tell me, that's not possible, because I've been doing that for decades. In Java that is.

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

troupo 3y ago

> Errors happen in response to conditions that occur during the execution of the application. Exceptions happen in response to conditions that occurred when the code was written. wat. You have code that ends up dividing by zero, and boom, you have an exception while the app is running. > It is highly unlikely that you want to handle an exception. You always want to handle an exception. That is how actual resilient systems are written

troupo 3y ago
Got downvoted. Do read Joe Armstrong's Making reliable distributed systems in the presence of software errors https://erlang.org/download/armstrong_thesis_2003.pdf https://erlang.org/download/armstrong_thesis_2003.pdf
randomdata 3y ago
> You have code that ends up dividing by zero, and boom, you have an exception while the app is running. Yes, and? That problem arose when the code was written. There is no reason why a program should ever find itself in a state where division by zero can occur. A simple if statement is all it takes to avoid that. If you see a divide by zero exception, the developer fucked up; having wrote an incorrect program. That's entirely different to, say, a hard drive crash causing writes to fail. Not even an ideal programmer writing an ideal piece of software completely void of all defects can avoid an error condition. > You always want to handle an exception. No. You always want to ensure that you have no exceptions in the first place. They are the runtime equivalent of compiler errors. If you encounter an exception in your software, you screwed up. There are circumstances where handling exceptions is warranted, but if you are routinely handling exceptions throughout your development, something is amiss.
- Gibbon1 3y ago
  Once you get outside webshit you have a world where things need to be able to get the job done even in the presence of software bugs. And software bugs are just another type of failure. Some of those involve cases where failure is expensive or life threatening.