The day I send myself about 76k mails
> be me
> be working on a rest api
> implement an error handler that would send me a mail with exception details
> use same error handler in mail send error handler
> Summoned the recursion devil by accident
> Test error handler
> Forgot port forwarding to SMTP server
> keep the debug session open
> throw new UnexpectedInterruptionException()
> get back to work
> Add the missing port forwarding rule to putty
> The error handler starts doing it's thing
> The handler chain starts to pop
> handler after handler executes
> PCFreeze.png
> WhatTheFuckIsGoingOn.gif
> VS finally accepts stop debugging
> PhoneVibrationSpam.mp3
> Peek into webmail
> WowFinallySomeFanMail
> Look into it
> Realizing what I have done
> Delete mailbox
> Remove recursion
> Wow that's how randy must have felt in southpark
> Feel weird
> Shutdown, go outside
> What's up anon?
> Nothing, really

Besides the fact that there would be an error handler, wouldn't it store a phone number as an object other than a computable number, like a string, cuz phone number is like a handler, a reference, and not something you'd ever perform arithmetic on?

Did a bunch more cowboy coding today as I call it (coding in vi on production). Gather 'round kiddies, uncle Logan's got a story fer ya…

First things first, disclaimer: I'm no sysadmin. I respect sysadmins and the work they do, but I'm the first to admit my strengths definitely lie more in writing programs rather than running servers.

Anyhow, I recently inherited someone else's codebase (the story of my profession career, but I digress) and let me tell you this thing has amateur hour written all over it. It's written in PHP and JavaScript by a self-taught programmer who apparently discovered procedural programming and decided there was nothing left to learn and stopped there (no disrespect to self-taught programmers).

I could rant for days about the various problems this codebase has, but today I have a very specific story to tell. A story about errors and logs.

And it all started when I noticed the disk space on our server was gradually decreasing.

So today I logged onto our API server (Ubuntu running Apache/PHP) and did a df -h to check the disk space, and was surprised to see that it had noticeably decreased since the last time I'd checked when everything was running smoothly. But seeing as this server does not store any persistent customer data (we have a separate db server) and purely hosts the stateless API, it should NOT be consuming disk space over time at all.

The only thing I could think of was the logs, but the logs were very quiet, just the odd benign message that was fully expected. Just to be sure I did an ls -Sh to check the size of the logs, and while some of them were a little big, nothing over a few megs. Nothing to account for gigabytes of disk space gradually disappearing.

What could it be? I wondered.

cd ../..
du . | sort --sort=numeric

What's this? 2671132 K in some log folder buried in the api source code? I cd into it and it turns out there are separate PHP log files in there, split up by customer, so that each customer of ours (we have 120) has their own respective error log! (Why??)

Armed with this newfound piece of (still rather unbelievable) evidence I perform a mad scramble to search the codebase for where this extra logging is happening and sure enough I find a custom PHP error handler that is capturing (most) errors and redirecting them to these individualized log files.

Conveniently enough, not ALL errors were being absorbed though, so I still knew the main error_log was working (and any time I explicitly error_logged it would go there, so I was none the wiser that this other error-catching was even happening).

Needless to say I removed the code as quickly as I found it, tail -f'd the error_log and to my dismay it was being absolutely flooded with syntax errors, runtime PHP exceptions, warnings galore, and all sorts of other things.

My jaw almost hit the floor. I've been with this company for 6 months and had no idea these errors were even happening!

The sad thing was how easy to fix all the errors ended up being. Most of them were "undefined index" errors that could have been completely avoided with a simple isset() check, but instead ended up throwing an exception, nullifying any code that came after it.

Anyway kids, the moral of the story is don't split up your log files. It makes absolutely no sense and can end up obscuring easily fixable bugs for half a year or more!

Happy coding.

*Senior Dev:* Ah yes, we need to put try-catch in every function to handle errors and Logger.Log() at the beginning.
*Me:* Is not better to define a global error handler and use the stacktrace instead of doing all that?
*Senior Dev*: ...
*Senior Dev*: Is a rule here, do what I'm telling you.

A client is like: Help! We got a 500 in our wordpress administration panel and there is no error in the log, it must be your infrastructure at fault!

So I calmly replied to them that wordpress handles its errors on its own, and without the appropriate debug flags enabled, doesn't log it anywhere. Even mentioned that a PHP app can change the error handler no problem, and linked them to both, PHP and Word press docummentation.

Didn't hear from them since.

So there’s this SOAP api I have to use (not by choice, and not the only one i have to use) that returns a bunch of XML nodes to confirm the data sent made it and checks out - pretty standard stuff yea.

Now every once in a while it doesn’t respond (as far as I could tell) so today I wrapped a debug around the soap call, error handler and responses and threw a bunch of messages it’s way to try and force it not to respond in order to be able to put some decent error handling in place.

Well it wouldn’t fail.
100 messages .... all responses good
100 more.... all responses good

And then 100 more.... all respond with “x”, plain text not XML as expected!

Wtf is this shit!!!!!

So a new dev had an issue, if the wrong credentials are in the code it will crash because the unauthorised error isn't being handled.

I physically added the error handler, to his code, on his machine ... 3 days later it's not there.

Asked him and he says "sorry I must have deleted it"

... that's grounds for dismissal right? ... like ... seriously

So normally I go with a super-conservative error handler that logs errors, and exit the process on even the tinyest/smallest error.
Regardless or project/cms/framework I always to this to prevent myself from installing spaghetti plugins or writing unstable code.
Also because I don't want any code to just soldier on if a variable wasn't defined properly, or likewise.

But today I had to write this little fucker into my error handler, to support the error surpressing operator '@'

Appearently prestashop was developed by a group of senseless moronic fuckwits,
and hteir piece of horseshit software doesn't even work if it isn't allowed to surpress errors.

What was the fucking imbeciles thinking when requiring such lunatic behaviour...

Legacy code again.... found this... losing faith...

So.. I'm giving one of my employers webapps a visual refresher, new company branding and whatnot.

And then I stumbled onto a check that is not returning what anybody expects, and, well , I'm busy fixing things, yeah..? so I go digging.. 🤔

```
function isDefined(obj) {
return !(typeof obj === "undefined") || obj !== null;
}
```

Here's the fun part, these particular lines have been in the code base since before 2017, which is when my Git history starts, because that's when we migrated projects from Visual SourceSafe 6 over to Git. Yes, you read that right. They were still using VSS in 2017.

I've begged and pleaded with my last 3 bosses to let us thrown this piece of shit out our second story window and rewrite it properly. But no, we don't have time to rewrite, so we must fix what we have instead.

I lost 4 hours of my life earlier today, tracking down another error that has been silently swallowed by a handler with its "console.log" call commented out, only to find that it's always been like that, and it's an "expected error". 🤦

Please, just fucking kill me now... I just, I can't deal with this shit anymore.

I fucking hate Visual Studio!

Don't get me wrong, from time to time I actually enjoy it but not today.
It all went south when I tried to add a new handler to an fucking old asp.net webpage. I had the access the 'Range' headed to stream bits of audio and video files to the client. It was working absolutely fine for the first hour and a half, after that point the fun started...
VS decided that my source code and the binaries won't match anymore. Everytime I tried to add a fucking breakpoint or debug this cunt of an error it would just refuse
The worst part that made me go apeshit was when I finally got a breakpoint and the exception. Some unknown fucking system dll just kept on killing my thread without a proper error message because it's optimized to the fucking moon and back!

Any ideas from the devs here on what's going on and how the fuck I can fix this?

So I made an update to my React Native app. I changed UI of a couple of screen, added a few animations here and there, refactored how my graphQL resolvers work in the backend(no breaking changes), changed how data gets loaded into the database etc.

It worked in dev so I figured hey let's deploy it. Today is(was because it's now 3am but more on that later) a national holiday so no one goes to work so no one will use my app so I have an entire day to deploy.

I started at 15:00(because i woke up at 13:00 lol). I tested the update once again in dev and proceeded to deploy it to prod. I merged backend to master, built docker images, did migrations on the db, restarted docker-compose with new images. And now for the app. I run ./gradlew assembleRelease and it starts complaining that react-native-gesture-handler is not installed. Ugh, rm -rf node_modules && yarn install. It worked. But now gradlew crashes and logs don't tell me anything. Google tells me to change a bunch of gradle settings but none of them work. Fast forward 5h, it's around 20:00 and I isolated the issue to, again, react-native-gesture-handler. They updated from 2.2.4 to 2.3.0 which didn't fucking compile. 2 more hours passed (now 22:00) and I got v2.3.1 working which fixed the problem in 2.3.0 but made my app crash on startup. YOUR FUCKING LIBRARY GETS 250K WEEKLY DOWNLOADS AND YOU DONT EVEN BOTHER CHECKING IF IT COMPILES IN PROD ON ANDROID?! WHAT THE FUCK software-mansion?

After I solved that, my app didn't crash. Now it threw an error "Type errors: Network Request Failed" every time I fetch my legacy REST API(older parts use rest and newer use graphql. I'll refactor that in the next update). I'll spare you the debugging hell i went through but another 5h passed. Its 3am. My config had misspelled url to prod but good for dev... I hate myself and even more so react-native-gesture-handler.

FML!!!!!! I FUCKING HATE THE COMBINATION OF XAMARIN FORMS AND MY COWORKERS.

Explanation:

I had to refactor all of our views because my coworkers did anything in the code-behind file from the views but the code should be in the viewmodels.

I had an "Unhandlex Exception" without any stacktrace or error message for a hour. What was the error? In the xaml file of the view was still an OnClicked-handler of a button but i removed the method from the view-code-behind-file.

FML

Magento Debugging Horror!
Changing lots of things in magento with no problem. Continuing development for quite sometime. Suddenly decide to clear cache to see affect of a change on a template in frontent. Suddenly magento crashes! There's no error message. No exception log. No log in any file anywhere on the disk. All that happens is that magento suddenly returns you to the home page!
Reverting all the changes to the template. Clear the cache. Nope! Still the same! Why? Because the problem has happened somewhere in your code. Magento just didn't face it, because it was using an older version of your code. How? Because magento 2 even caches code! Not the php opcache. Don't get me wrong. It has it's own cache for code, in a folder called generated. Now that you cleared all the caches including this folder, you just realized that, somewhere something is wrong. But there is no way for you to know where as there is absolutely no exception logged anywhere!
So you debug the code, from index.php, down to the deepest levels of hell. In a normal php code, once the exception happens, you should see the control jumps to an exception handler, there, you can see the exception object and its call stack in your debugger. But that's not the case with magento.
Your debugger suddenly jumps to a function named:
write_close();
That's all. No exception object. No call stack. No way to figure out why it failed. So you decide to debug into each and every step to figure out where it crashes. The way magento renders response to each request is that, it calls a plugin, which calls a plugin loop, which calls another plugin, which calls a list of plugins, which calls a plugin loop, which calls another plugin.....
And if in each step, just by accident, instead of step through, you use the step over command of your debugger, the crash happens suddenly and you end up with the same freaking write_close() function with no idea what went wrong and where the error happened! You spend a whole day, to figure out, that this is actually a bug in core of magento, they simply introduced after your recent update of magento core to the latest STABLE version!!! It was not your mistake. They ruined their own code for the thousandth of time. You just didn't notice it, because as I said, you didn't clear the `generated` folder, therefore using an older version of everything!
Now that after spending 7 hours figuring out what has failed with absolutely no standard way of debugging and within a spaghetti of GOTO commands (Magento calls them plugin), why not report it to github? So you report it with a pull request. This also takes 1 hour of your time. Just to next day get informed that your pull request is rejected because another person already fixed the bug and made the same pull request. It was just not on the latest stable version yet!
So you decide to avoid updating magento as much as possible. Because you know that the next Stable version will make your life and career unstable. But then the customer complains that the Admin Panel is warning him of using old Magento version which might pose SECURITY THREATS!

Which php framework is worth getting into? Laravel seems to have most market or should I go with CakePHP or even something else? any info is appreciated (how are the docs, is it hard to find solutions, how is the error handler, how hard is it to learn etc), I am sure people around here have used a good amount of them and can tell their rage or good things about it. 😳

Form plugin for WordPress on a seriously out of date install won't update until I update WordPress core. Fine, I update core and update the plugin and test the forms again. Form still isn't sending emails on submission. Look into forms settings. Oh look error messages, awesome!

Message: "There are 2 configuration errors"

OK, what are the errors where are the errors?

"There are two configuration errors."

Gee that's really fucking helpful, why even tell me you can see the errors if you aren't going to fucking tell me where the blasted things are. Spend 4 fucking hours trying to figure this out, checking "docs" wiki, support forums, nothing.

Finally decided to just trash the client's form plugin they were using and installed my reliable Gravity Forms.

P.S. if you are going to write code to find errors, and tell me about them, then you had better fucking tell me what the goddamned error is. There is no need to waste a developer's time trying to debug your shitty plugin because you couldn't be bothered to write a useful error handler.

I think I understand now why people dislike continuation passing style for side effects. The continuations passed to the action can be called in any pattern, there's no inherent guarantee that an error handler cannot be called just because the corresponding success handler had already been called. In this regard they act like jump points in assembly more than functions in an equation.

I don't think this is such a massive problem. The entire imperative world is built on such things. I definitely think though that this model does not mix with autocurry.

I spent three days debugging an API endpoint because in this framework, a "function not in scope" error fails silently. The only way to find out that this issue was happening was to drop the entire endpoint handler into a try/catch block.

Guys.
JavaScript is the shittiest fucking language.

I just wrote an error handler in php (would trigger only if the user's stupid enough):

if (!$detail_trans && !header_moved) {
die("asshole");
}

when users give you a good bug title!!! :)

"Error executing child request for handler"

Error in exception handler.

Can the error types of my library depend on a custom library context object to be printable or otherwise meaningful? Pretty much everything else depends on this context, but until now the errors were an exception (no pun intended) because I wanted them to be printable by any handler that bumps into them, without scoping concerns. Now I tried removing them and like a third of my library has suddenly become context-free, because it only used the context to fully resolve everything before error reporting.