User Controls
Web developers whom piss me off, cause they''re noob fucks.
-
2015-06-30 at 12:34 PM UTCThem faggots who handle forms like so:
$address = $_POST['address'];
Like what're you doing, are you just fixin' for an error, or do you script with error reports off like a cunt?
See, no more error:
$address = isset($_POST['address']) ? $_POST['address'] : null;
and before asking, you don't sanatize before going in to the database -- that's just asking for trouble, you sanatatize when you grab the info from the database -
2015-07-01 at 4:35 AM UTClol.
In all seriousness though, I think it's Flask, or another one of python's "micro-frameworks", that does this cool thing where your request params looks like a dictionary(map) but when you try to access an unset key it throws a custom exception which the router catches and returns a 4xx response with like "missing request param" or something. I know java dweebs cry about using exceptions for control flow like that but it's a really nice approach I think, from a programmer perspective at least. -
2015-07-02 at 11:49 AM UTCJust use get.
$password = $_GET['password'];
-
2015-07-04 at 2:54 AM UTCI don't even know if you niggers are retarded or what
-
2015-07-04 at 11:38 AM UTC
Just use get.
$password = $_GET['password'];
lol you trrollin? -
2015-07-04 at 11:39 AM UTC
I don't even know if you niggers are retarded or what
me? -
2015-07-05 at 10:06 AM UTCToo much php up in this thread.
-
2015-07-09 at 1:36 AM UTC
me?
Yee. I didn't actually know that it produces warns because I leave them off (because injecting an error message into the markup is top-tier dumb, like most things in php. In fact PHP's whole "shit stdout into a socket" approach is highly questionable vestigial behaviour from CGI but if you know that's the case there's no excuse for polluting your output stream (which you know is a wire away from a parser) with error messages (which don't actually get logged anywhere by default)). If you care if a key is set or not then fine, check it, but it's silly to check if a key is set and if it's not give the thing you were assigning it to the same value it would have gotten from the direct access. It's like doing this in python:
try:
foo = bar['baz']
except KeyError:
raise KeyError('No key "baz" in foo") -
2015-07-09 at 1:54 AM UTC
Yee. I didn't actually know that it produces warns because I leave them off (because injecting an error message into the markup is top-tier dumb, like most things in php. In fact PHP's whole "shit stdout into a socket" approach is highly questionable vestigial behaviour from CGI but if you know that's the case there's no excuse for polluting your output stream (which you know is a wire away from a parser) with error messages (which don't actually get logged anywhere by default)). If you care if a key is set or not then fine, check it, but it's silly to check if a key is set and if it's not give the thing you were assigning it to the same value it would have gotten from the direct access. It's like doing this in python:
try:
foo = bar['baz']
except KeyError:
raise KeyError('No key "baz" in foo")
Please don't ever PHP. -
2015-07-10 at 4:19 AM UTCWhy? Because I know how webdev is done in better languages?
-
2015-07-10 at 7:54 AM UTC
Why? Because I know how webdev is done in better languages?
Ha! No for the fact you turn error reporting off. Assuming I can't python *claps* Or assuming a website's just built with python unlike PHP -
2015-07-11 at 3:03 AM UTCI never said either nor assumed either of those things but my point that error reporting in php is fundamentally broken stands. It should be turned off, and if you really give a fuck you can wrap raw arrays or something.
-
2015-07-11 at 2:29 PM UTC
I never said either nor assumed either of those things but my point that error reporting in php is fundamentally broken stands. It should be turned off, and if you really give a fuck you can wrap raw arrays or something.
You just said:Yee. I didn't actually know that it produces warns because I leave them off
Hence my reply lol And php warnings should never, ever be turned off during development, only during live mode should it be turned off, and then you won't need it anyway with exceptions and shit, but during productions, it's needed, or be prepared to have deprecated warnings. I know a noob who still uses the MYSQL_ functions instead of PDO. fuck them. -
2015-07-11 at 6:55 PM UTC
You just said:
Hence my reply lol
I did but how does that imply that I assumed you don't know python or that "a website's just built with python unlike PHP" (whatever that means)?And php warnings should never, ever be turned off during development, only during live mode should it be turned off, and then you won't need it anyway with exceptions and shit, but during productions, it's needed, or be prepared to have deprecated warnings.
Why? I'm actually curious, I have limited PHP experience but I've never gotten a useful warn/error that wasn't better handled by a utility function that would throw an exception. You can't really use the case in OP because unset key access is defined behaviour and null checking without warn reporting or key presence checking with reporting is functionally equivalent.
A bit of a tangent, but do you write PHP in a professional capacity? I was thinking you were, but this:but during productions, it's needed
seems odd because, at least in my neck of the tech woods, "production" generally means the deployment environment/what customers get rather than the phase where you're writing/debugging.I know a noob who still uses the MYSQL_ functions instead of PDO. fuck them.
Yeah, PDO is the way to go if you're using a raw driver, it's what I used in my last jaunt into PHP. What's your opinion of PHP's ORMs? I've never used one (php orm that is, I've used orms in other languages though) but I like the look Doctrine's API relative to others I've seen. -
2015-07-11 at 7:46 PM UTC
Why? I'm actually curious, I have limited PHP experience but I've never gotten a useful warn/error that wasn't better handled by a utility function that would throw an exception.
Because throw new exception doesn't work for deprecated functions, which is happening more often since the new version of PHP is close to releaseA bit of a tangent, but do you write PHP in a professional capacity? I was thinking you were, but this:
seems odd because, at least in my neck of the tech woods, "production" generally means the deployment environment/what customers get rather than the phase where you're writing/debugging.
I meant development, just an error in wording.
and regarding the orms. I don't use 3rd party frameworks, so I can't comment on them, I built my own to use. -
2015-07-12 at 7:43 PM UTC
Because throw new exception doesn't work for deprecated functions, which is happening more often since the new version of PHP is close to release
Sure, but by and large cases where you get a warn to stdout instead of an exception you don't really need to unwind the stack (like in the case you use in your OP, you just "catch" the situation right away). Like in the case of your OP you can just assign, null check, and throw yourself or recover if possible. In fact I'll argue that's a somewhat better approach because if that situation happens when you're half way through document generation then it's entirely possible your warn is going to get shit into non-visible markup and the situation will be that much harder to detect. -
2015-07-12 at 8:04 PM UTC
Sure, but by and large cases where you get a warn to stdout instead of an exception you don't really need to unwind the stack (like in the case you use in your OP, you just "catch" the situation right away). Like in the case of your OP you can just assign, null check, and throw yourself or recover if possible. In fact I'll argue that's a somewhat better approach because if that situation happens when you're half way through document generation then it's entirely possible your warn is going to get shit into non-visible markup and the situation will be that much harder to detect.
no, because you don't want to throw an exception on a recoverable warning... e.g an empty form input, exceptions are for non-recoverable errors, which I'm sure you know. -
2015-07-15 at 2:36 AM UTC
no, because you don't want to throw an exception on a recoverable warning… e.g an empty form input, exceptions are for non-recoverable errors, which I'm sure you know.
That's... that's totally not true though. Exceptions are for, well, exceptional conditions. Some exceptional conditions are recoverable, some are not. There would not be a catch clause in the language if exceptions weren't supposed to be recoverable. Some languages get prickly about what recoverable means and how you subclass the throwable hierarchy (Java is what I'm thinking of here) and how checking goes with that (although the ideal and what you see dogshit blue collar programmers calling "best practices" are two very different things) but PHP is not one of them. -
2015-07-20 at 5:41 AM UTC
no, because you don't want to throw an exception on a recoverable warning… e.g an empty form input, exceptions are for non-recoverable errors, which I'm sure you know.
Yeah, I don't see how this would make sense. If you can catch an exception then it's pretty recoverable. If you know what kind of exception you want to catch at least. -
2021-10-26 at 1:52 AM UTCBump. Cuz this was the oldest thread on the last page of latest threads
Yw
