4 ms·

I would add that a error-handling strategy should never be a concern wrt performance because obviously the purpose of this sort of code is to serve as guard rai

I would add that a error-handling strategy should never be a concern wrt performance because obviously the purpose of this sort of code is to serve as guard rails and ideally never be called at all ever. If your error-handling code is triggered so often that you feel it might be causing a performance hit, you have far more serious problems than the performance overhead of how you handle errors.

aothms 7y ago
I mean, it depends, CGAL for example, which I'd consider a high quality software library, uses exceptions for their exact number type to redo the calculation using more precision when needed https://www.cgal.org/FAQ.html#uncertain_exception https://www.cgal.org/FAQ.html#uncertain_exception
- rumanator 7y ago
  You're invoking the appeal to authority fallacy. Just because a popular package adopted a practice that does not make it right or good or acceptable. If that line of argument made any sense, you could argue that bugs present in CGAL represent best practices. Rule of thumb: if a code path is not exceptional then it should not be implemented with exceptions. The happy path is not an exception.
sixplusone 7y ago
My web server gets about 1000 to 1 hits of hacking attempts to valid requests (malformed headers, etc.) so I hope nginx and fcgi handle errors efficiently, because I pay for those cycles.
- rumanator 7y ago
  You're not describing exceptional events. You're describing pretty much the happy path of any reverse proxy. In fact, in some applications these sort of events outnumber HTTP Status 200-worthy requests.
  - sixplusone 7y ago
    That's a strange idea of what "happy path" means. An invalid request is, by definition, an error or exception.
    - rumanator 7y ago
      That assertion is obviously wrong. Think about it: you have a web server listening to the world. Do you really expect all requests to be neatly pointing to sanitized URLs? Of course not. Why on Earth should you assume that handling invalid requests is not one of the primary use cases?
      - sixplusone 7y ago
        You and flqn are trying to convince me that expected errors are not errors https://en.wikipedia.org/wiki/Happy_path https://en.wikipedia.org/wiki/Happy_path When I want a parameter is an integer, I don't check all the ways in which it's NOT an integer; the happy path is when it _is_ an int and the program can continue, and anything else is an _Error_. If it overflows, that's an error too. i.e., happy means it's basically the longest path (aside from diagnosing the error). The question is: should the subroutine set an error number or throw an exception? Knowing the cost for each might help me decide for various situations.
- flqn 7y ago
  In those cases, a malformed request is common enough that discriminating between well-formed and malformed should be thought of like a first-class part of handling a request, not an error-handling situation. Errors are when things go wrong that you don't expect to usually go wrong* *for varying values of usually, YMMV, use your own judgement, etc

aothms 7y ago

I mean, it depends, CGAL for example, which I'd consider a high quality software library, uses exceptions for their exact number type to redo the calculation using more precision when needed https://www.cgal.org/FAQ.html#uncertain_exception https://www.cgal.org/FAQ.html#uncertain_exception

rumanator 7y ago
You're invoking the appeal to authority fallacy. Just because a popular package adopted a practice that does not make it right or good or acceptable. If that line of argument made any sense, you could argue that bugs present in CGAL represent best practices. Rule of thumb: if a code path is not exceptional then it should not be implemented with exceptions. The happy path is not an exception.

sixplusone 7y ago

My web server gets about 1000 to 1 hits of hacking attempts to valid requests (malformed headers, etc.) so I hope nginx and fcgi handle errors efficiently, because I pay for those cycles.

rumanator 7y ago
You're not describing exceptional events. You're describing pretty much the happy path of any reverse proxy. In fact, in some applications these sort of events outnumber HTTP Status 200-worthy requests.
- sixplusone 7y ago
  That's a strange idea of what "happy path" means. An invalid request is, by definition, an error or exception.
  - rumanator 7y ago
    That assertion is obviously wrong. Think about it: you have a web server listening to the world. Do you really expect all requests to be neatly pointing to sanitized URLs? Of course not. Why on Earth should you assume that handling invalid requests is not one of the primary use cases?
    - sixplusone 7y ago
      You and flqn are trying to convince me that expected errors are not errors https://en.wikipedia.org/wiki/Happy_path https://en.wikipedia.org/wiki/Happy_path When I want a parameter is an integer, I don't check all the ways in which it's NOT an integer; the happy path is when it _is_ an int and the program can continue, and anything else is an _Error_. If it overflows, that's an error too. i.e., happy means it's basically the longest path (aside from diagnosing the error). The question is: should the subroutine set an error number or throw an exception? Knowing the cost for each might help me decide for various situations.
flqn 7y ago
In those cases, a malformed request is common enough that discriminating between well-formed and malformed should be thought of like a first-class part of handling a request, not an error-handling situation. Errors are when things go wrong that you don't expect to usually go wrong* *for varying values of usually, YMMV, use your own judgement, etc