Good vs. Evil
- Thread starter Randomguy404
- Start date
-
The FTB Forum is now read-only, and is here as an archive. To participate in our community discussions, please join our Discord! https://ftb.team/discord
51 Now just to hope it holds up under the stress of the event itself. Don't have enough robots to do a stress test before then.
50 so.. I wanted to turn the output of errors from html to json. I somehow managed to make it work but.... it was a weird path.
step 1: Make php throw an error. This was simple enough, just make a basic syntax error.
step 2: notice how it was displayed in codeigniters format instead of my json format like exceptions are. (this one is important)
step 3: find possible view files that could be the error pages: I found error_php.php, error_general.php and error_exception.php (the last one I already modified to make exceptions appear as json. Again, important)
step 4: use trial and error to see which of the 3 got loaded. I found out it was error_php.
step 5: make it turn the error into json
step 6: after you are done, turn off the code
step 7: discover errors are still shown as json
step 8: discover that a parse error actually uses error_exception.
step 9 write this post in the GvE thread about having no idea how this all happened.
I wonder what view will be used next >_>
step 1: Make php throw an error. This was simple enough, just make a basic syntax error.
step 2: notice how it was displayed in codeigniters format instead of my json format like exceptions are. (this one is important)
step 3: find possible view files that could be the error pages: I found error_php.php, error_general.php and error_exception.php (the last one I already modified to make exceptions appear as json. Again, important)
step 4: use trial and error to see which of the 3 got loaded. I found out it was error_php.
step 5: make it turn the error into json
step 6: after you are done, turn off the code
step 7: discover errors are still shown as json
step 8: discover that a parse error actually uses error_exception.
step 9 write this post in the GvE thread about having no idea how this all happened.
I wonder what view will be used next >_>
50. I like how step 9 is already incorporated in your coding process for segments of things you do 
51 also, I think I know what happened.
The syntax error was in the controller file that was being loaded, which meant that codeigniter couldn't create a controller instance.
My output class(which is responsible for generating the json output) wants a reference to the current controller as it needs some stuff that you can only get that way(mainly code igniter's own output class).
My guess is that code igniter, upon failing to load the controller due to the syntax error went to the exception view. This loaded my own output class which also crashed and rather than trying to load the exception view again code igniter loaded the error_php view.
This meant that it looked like it loaded the error_php file, when it was only its second choice.
The syntax error was in the controller file that was being loaded, which meant that codeigniter couldn't create a controller instance.
My output class(which is responsible for generating the json output) wants a reference to the current controller as it needs some stuff that you can only get that way(mainly code igniter's own output class).
My guess is that code igniter, upon failing to load the controller due to the syntax error went to the exception view. This loaded my own output class which also crashed and rather than trying to load the exception view again code igniter loaded the error_php view.
This meant that it looked like it loaded the error_php file, when it was only its second choice.
51 well, it means that there is a fallback in place for if the exception view couldn't do its job. It however also means that I don't know when the error_php view gets loaded except as a fallback.
If its just the fallback I'm probably going to revert it as that one is proven to work and the simpler it is the better. However, if it also serves some other purpose, then I am not much further.
I guess I need to trigger a warning and see what happens.
Yes, that is also a thing in php. For the record, A warning is similar to an error except that it won't stop the script from running.
So.... a recap:
Exception: This is most often created by your code on purpose. It will bubble up the callstack, killing everything in its path until it reaches a try/catch block made to catch it. An example could be that someone tried to login with a username that didn't exist.
Error: Similar to Exceptions except that they where part of the language before exceptions where a thing. You can't use a try/catch block to catch them but need to do some other trickery to detect them. In a proper language they shouldn't exist and instead every single one of them would be an exception. An example could be that a script you tried to load doesn't exist or can't run for other reasons.
Warnings: Similar to an error, except they don't stop the script from executing AND pollute your output by placing warnings inside of it. Many of them should have just been errors (Which again should have been exceptions). An example is that a POST request contained more data than php is allowed to work with. Yes, in those case it just truncates whatever it couldn't process and continues executing the script without you being able to detect that it happened. Yes I complained about it before but WTF! THIS IS SUCH IDIOTIC BEHAVIOR AND IT SHOULD JUST BE AN ERROR AND NOT A *@#(% WARNING!
its like going to a restaurant with some friends and the waiter only writing half of your orders down because he ran out of paper and didn't tell you about it. Which obviously results in you only getting half of it and someone dieing because the waiter couldn't write the warning down that one of your friends was allergic for something that would normally be included but decided to order anyway as the waiter promised to make sure his/her dish would be prepared without it..
If its just the fallback I'm probably going to revert it as that one is proven to work and the simpler it is the better. However, if it also serves some other purpose, then I am not much further.
I guess I need to trigger a warning and see what happens.
Yes, that is also a thing in php. For the record, A warning is similar to an error except that it won't stop the script from running.
So.... a recap:
Exception: This is most often created by your code on purpose. It will bubble up the callstack, killing everything in its path until it reaches a try/catch block made to catch it. An example could be that someone tried to login with a username that didn't exist.
Error: Similar to Exceptions except that they where part of the language before exceptions where a thing. You can't use a try/catch block to catch them but need to do some other trickery to detect them. In a proper language they shouldn't exist and instead every single one of them would be an exception. An example could be that a script you tried to load doesn't exist or can't run for other reasons.
Warnings: Similar to an error, except they don't stop the script from executing AND pollute your output by placing warnings inside of it. Many of them should have just been errors (Which again should have been exceptions). An example is that a POST request contained more data than php is allowed to work with. Yes, in those case it just truncates whatever it couldn't process and continues executing the script without you being able to detect that it happened. Yes I complained about it before but WTF! THIS IS SUCH IDIOTIC BEHAVIOR AND IT SHOULD JUST BE AN ERROR AND NOT A *@#(% WARNING!
its like going to a restaurant with some friends and the waiter only writing half of your orders down because he ran out of paper and didn't tell you about it. Which obviously results in you only getting half of it and someone dieing because the waiter couldn't write the warning down that one of your friends was allergic for something that would normally be included but decided to order anyway as the waiter promised to make sure his/her dish would be prepared without it..
51.
That’s a much less common secondary use, compared to the vastly more prevalent meaning to wish you luck.
Not at all!
That’s a much less common secondary use, compared to the vastly more prevalent meaning to wish you luck.
50 I hate how the keyword "this" in JS doesn't refer to the object that made a method but instead has some other insane rules.
Its easy to work around it, but its ugly >_<.
For those that don't know what I'm talking about. Lets say I have a "car" object. Now, this will obviously have a method to accelerate. So, something like
Here, the keyword "this" refers to the car object, as that is the object the accelerate method is part of. Simple enough so far. Lets say, that for some reason another object can also make this car go faster. (Maybe its engine broke and is being pulled or something). In those cases we can just pass the accelerate function to the object that will make it go faster
In normal languages the work "this" in car.accelerate still points to the car object so when we do
However, in JS that isn't quite the case. Instead "this" now suddenly refers to pullingCar instead of car. Why? Ask the guy that designed it/the guy that asked for JS to be created in 10 days.
Anyway. The work around is to not copy the method but instead of putting an so called "arrow" function around it. Which would make the code more like
Now, this may not sound too bad. But lets say you also want to have something else happen in the accelerateCar method, considering its already wrapped in another method anyway. You may think that something like
Would do the trick. However, it isn't. Because in these examples we used an object dirrectly. MEANING that the keyword "this" INSIDE the arrow function does NOT point "pullingCar" because that did not exist yet when we made that function. INSTEAD it points to whatever "this" refers to in the code that created pulling car. Or in our case its the so called "window" object AKA the thing where all our globals are stored.
Don't follow it? Don't worry. Lots of people don't. Just know that for me right now I'm working with a system where different parts can only exist as objects and can only communicate with each other by passing methods. Meaning that every time I want to pass some kind of information between components (Which happens a lot) I need to first wrap said method in an arrow function before I can actually do anything with it. And if I ever forget, I end up that it runs the method on the wrong object which if I'm lucky just crashes the application but.... other stuff may happen instead depending on what the method was supposed to do.[/SPOILER]
Its easy to work around it, but its ugly >_<.
For those that don't know what I'm talking about. Lets say I have a "car" object. Now, this will obviously have a method to accelerate. So, something like
Code:
car = {
currentSpeed = 10
accelerate(){
this.currentSpeed = this.currentSpeed + 1;
}
}
print(car.currentSpeed) //this prints 10
car.accelerate()
print(car.currentSpeed)//this prints 11
Code:
pullingCar = {
accelerateCar = car.accelerate
}
Code:
print(car.currentSpeed)//this now prints 11 (from last time)
pullingCar.accelerateCar()
print(car.currentSpeed) //and now it prints 12, as the car got faster.Anyway. The work around is to not copy the method but instead of putting an so called "arrow" function around it. Which would make the code more like
Code:
pullingCar = {
accelerateCar = ()=>car.accelerate()
}Now, this may not sound too bad. But lets say you also want to have something else happen in the accelerateCar method, considering its already wrapped in another method anyway. You may think that something like
Code:
pullingCar = {
accelerateCar = ()=>{
car.accelerate()
this.doSomethingElse()
}
}52 its such so much that people start refusing to use the "this" keyword and instead use parameters.
Basically, they are doing it Lua's way without the nice syntax sugar that lua provides.
in lua that would be
Actually, it works similarly with python but that has at least some syntax sugar, thus you only need to set the "self" parameter when creating the method and don't have to worry about it when calling it.
However, some of these people also refuse to use const, arrow functions, classes and probably some other stuff.
The reason for that basically boils down to "these do the same as those other things, but are more limited". combined with "There should only be one way to do something"
That is fair enough for classes, as the prototype system is good enough (and in JS a class is just syntax sugar for the prototype system) and if you don't use "this" arrow functions aren't as useful I admit but...
vs
Also, their way means they first need to create a custom version of Array.prototype.map which takes the array to work on instead of using this like the standard implementation does.
Basically, they are doing it Lua's way without the nice syntax sugar that lua provides.
Code:
car = {
accelerate(car){
car.speed= car.speed + 1
}
}
car.accelerate(car)
Code:
car = {}
function car:accelerate()
self.speed = self.speed + 1
end
car:accelerate()Actually, it works similarly with python but that has at least some syntax sugar, thus you only need to set the "self" parameter when creating the method and don't have to worry about it when calling it.
However, some of these people also refuse to use const, arrow functions, classes and probably some other stuff.
The reason for that basically boils down to "these do the same as those other things, but are more limited". combined with "There should only be one way to do something"
That is fair enough for classes, as the prototype system is good enough (and in JS a class is just syntax sugar for the prototype system) and if you don't use "this" arrow functions aren't as useful I admit but...
Code:
something.map(something,function(v) {return somethingElse.doStuff(somethingElse,v) || thisOtherThing.doSomething(thisOtherThing,somethingElse.anotherThing(somethingElse,v),v);})
Code:
something.map(v=>somethingElse.doStuff(v) || thisOtherThing.doSomething(somethingElse.anotherThing(v),v))