3 ms·

>PHP Oh no, don't even put them in the same sentence. I am no fan of Go, but its error handling approach is beautiful compared to PHP. Every time I call an int

>PHP Oh no, don't even put them in the same sentence. I am no fan of Go, but its error handling approach is beautiful compared to PHP. Every time I call an internal function I have to go through the docs — does it return a NULL, an int, a boolean, or something else? Does 0 signal an error condition, or is it a valid value? Do I have to perform a strict check for NULL/false then? Or is it -1 (see link below)? The situation is generally better with third-party libraries though — they tend to just throw exceptions (if that matches your definition of "better"). https://www.php.net/manual/en/function.openssl-verify.php https://www.php.net/manual/en/function.openssl-verify.php

mey 7y ago
PHP is a bit of hyperbole, but otherwise correct. :) Ruby, Python, Javascript all support exceptions. PHP does support exceptions, but it's core libraries do not use them. Gotta trust PHP to do the worst of both worlds approach. Perl 6 has it but not sure where the world is in the 5 -> 6 migration. I'm not going to count eval(...) as exception handling as a language feature in Perl 5. :)
- chromatic 7y ago
  I'm not going to count eval(...) as exception handling as a language feature in Perl 5. :) You should. It's a perfectly valid exception handling mechanism. It's unfortunate that the name "eval" is overloaded for two separate behaviors: * catch exceptions thrown as strings or objects * compile and execute code from a string Other than the name, they're different behaviors.
  - mey 7y ago
    I am not a Perl expert. Only worked on some simple install tools written it a couple years ago. Re-reading docs, eval(...) traps exceptions (die), but requires manual inspection of error state, instead of automatically halting. It operates more like Go/C/PHP in that regard.
alyandon 7y ago
Rightly or wrongly, many PHP functions are thin wrappers around third-party C libraries and they tend to return values without interpretation of the results. For your example of openssl_verify see https://linux.die.net/man/3/x509_verify_cert https://linux.die.net/man/3/x509_verify_cert It can certainly be confusing but at least it is documented.
- PhasmaFelis 7y ago
  I'm curious who it was who first started implementing those wrappers and thought "Yeah, this is good enough."
  - mkr-hn 7y ago
    The late '90s and early '00s were a strange time. It had plenty of shotguns aimed at feet and no one to suggest a better approach. At least no one with enough reach. Also [1]: >> "I don't know how to stop it, there was never any intent to write a programming language [...] I have absolutely no idea how to write a programming language, I just kept adding the next logical step on the way" I assume he's better at it 16 years later. [1] https://en.wikipedia.org/wiki/PHP#History https://en.wikipedia.org/wiki/PHP#History

mey 7y ago

PHP is a bit of hyperbole, but otherwise correct. :) Ruby, Python, Javascript all support exceptions. PHP does support exceptions, but it's core libraries do not use them. Gotta trust PHP to do the worst of both worlds approach. Perl 6 has it but not sure where the world is in the 5 -> 6 migration. I'm not going to count eval(...) as exception handling as a language feature in Perl 5. :)

chromatic 7y ago
I'm not going to count eval(...) as exception handling as a language feature in Perl 5. :) You should. It's a perfectly valid exception handling mechanism. It's unfortunate that the name "eval" is overloaded for two separate behaviors: * catch exceptions thrown as strings or objects * compile and execute code from a string Other than the name, they're different behaviors.
- mey 7y ago
  I am not a Perl expert. Only worked on some simple install tools written it a couple years ago. Re-reading docs, eval(...) traps exceptions (die), but requires manual inspection of error state, instead of automatically halting. It operates more like Go/C/PHP in that regard.

alyandon 7y ago

Rightly or wrongly, many PHP functions are thin wrappers around third-party C libraries and they tend to return values without interpretation of the results. For your example of openssl_verify see https://linux.die.net/man/3/x509_verify_cert https://linux.die.net/man/3/x509_verify_cert It can certainly be confusing but at least it is documented.

PhasmaFelis 7y ago
I'm curious who it was who first started implementing those wrappers and thought "Yeah, this is good enough."
- mkr-hn 7y ago
  The late '90s and early '00s were a strange time. It had plenty of shotguns aimed at feet and no one to suggest a better approach. At least no one with enough reach. Also [1]: >> "I don't know how to stop it, there was never any intent to write a programming language [...] I have absolutely no idea how to write a programming language, I just kept adding the next logical step on the way" I assume he's better at it 16 years later. [1] https://en.wikipedia.org/wiki/PHP#History https://en.wikipedia.org/wiki/PHP#History