We just finished a major project 2 days after its deadline. By we, I meant me (fumbling to understand what is going on in this program) and my boss (who instructs me most of the way).
What the client wanted in the program: When a person approves a request made to him, that request in csv format will download automatically to a different server's folder.
What I don't understand (not yet anyway): How to download csv file to a specific folder.
After a bunch of trial and errors, and hints from StackOverflow, I got cURL. With cURL, I was able to download a csv file whenever I went to its web link. That csv file saves to wherever the cURL file was located. From now on, I'll call this file with cURL in it as listen.php.
Yey! Atleast I know that listen.php really downloads something.
The next problem: I need to pass dynamic data to that csv. As it is, it is only accessible when I go to the page directly, where listen.php is, and the csv just inputs 302 error.
So I need to POST from my controller the data to that listen.php file. That listen.php file will then go to the link, and hopefully download the correct csv file. My problem was in the sending part: how do I send $_POST data without a form, or submit button or js?
Boss' advice: Research guzzle.
And I said: (verbatim in Tagalog: "Tama ba pagkakaintindi ko sir? Magpopost ako from my controller to listen.php?") Do I understand it correctly? I will post the data from the controller to listen.php?
He replied: Yes, that's correct. "Yes". (Tama daw.)
After reading the request part of Guzzle docs, and copying and modifying its sample code, I was able to pass data to listen.php. Yey! And that file downloads. I know the data I passed was correct because the csv file's name was correct and dynamic. I passed the title of the csv in the POST request as well.
But inside that csv was a bunch of different errors.
The next problem: So I was able to download a csv file, but this file only contained:
a) blank page
b) 302 redirect error
c) csv file but contained html code with stacktrace of errors
I tried a few different things, of which I forgot which specifically, which resulted to the 3 kinds of errors I had.
I have a tendency to run AWAY from errors. Whenever I couldn't understand a specific set, or I'm stuck on a task, I go to another task down the list. I don't think it's efficient but I just feel better when I get a task done, even if it's a easy or minor one.
I think this is mainly why I take longer on projects. I tend to have a bunch of hard problems to solve whenever the deadline is nearing.
This creates more panic.
Then I can't think properly and be focused because I am worrying on the deadline nearing and I can't solve it.
Deadly cycles continues.
And when I got the csv file with the stacktrace errors, my instinct was to try another "hack" I found in StackOverflow, instead of finding the error in the stacktrace.
Do I wish to have errors pop out, or have a blank page that doesn't have errors (but is still not working) instead? I'll opt for the error page anytime. But they still scare me.
My boss said it would be good if the errors blow up so we could see the errors. Atleast then we have a clue where to look.
I feel like an investigator Detective Conan. But instead of dead bodies, I find pages not working and why.
How do you feel about errors in your program?
Top comments (4)
Ha, yeah. Looking through any type of 'logs' generally makes my head spin. But definitely better than having no errors to reference!
Error handling is something you get better at over time, but it IS one of the most important things when your target is to create quality software.
Dumping errors on the output is one of the worst options you can do, even if you do it just on some internal projects - it trains you to think it's ok, and then you leave it on in production for some project where it's not ok (most professional cases really), and you end up with awful looking websites and potentially severe security issues.
Set up a proper error handler and return a nice error page, e.g. with Nginx/Apache, or via other means, and log your errors somewhere. Any decent web application framework (which you definitely should be using if you're not very experienced) should also include ways to set up nice looking error pages ("Oops, something went wrong. Please try again later." -type stuff)
google.com/search?q=nginx+error+page
Digging through server logs can be understandably dreadful, but products like sentry.io can help make that a LOT less painful, without incurring a significant cost.
Please spend time, significant time, thinking of exception and other error handling, validation, and monitoring instead of just letting your programs crash in whatever ways they feel like and dumping the raw errors to browsers.
Errors shouldn't be dreaded, but treated with respect - errors happen, even during 100% correct behavior and usage, and you should write your code in a way that handles them as cleanly and thoughtfully as possible.
Thank you for the advice. I hope to get bettee at error handling over time. We do have some Bugsnag and custom error pages set up. And we put it in that particular program as well.
As always: it depends. I dislike things that stop me, and I (really) like challenges.
Typical stoppers are relatively trivial errors like linting, syntax errors.
The weirder errors and bugs get, the more excited I become because I know they are great opportunities to learn. On several occasions, I've spent an entire day diving into a single bug.
Either way: it gets easier over time.