Small errors can be hard to find, especially in complex setups with misleading warnings pointing in a completely wrong direction. But let's appreciate the positive effects of "wasting" hours in finding an error, if it's done correctly, because detours can expand our knowledge of our surroundings!
Wasting Time in a Productive Way
As I claimed in the discussion about "productive procrastination" it might benefit in the long run to "waste" time learning or building code.
Maybe Shopware, a company building e-commerce software based on the Symfony framework, had similar thoughts when they decided not to amend their official developer tutorial videos. Apart from some information getting outdated due to new software releases, some parts of the code shown in the tutorial are wrong or incomplete, so it's up to you as a developer, to make your application work anyway.
When I come back to that training tutorials between paid project periods, I often find I forgot a lot of what I learned last time, and when I look at my old notes, I find that I keep making the same mistakes twice or three times before finally achieving a profound knowledge and not having to look it all up anymore.
It might be sad or rather funny, that sometimes all I see when googling (or ecosing) an error message are my own posts, written two years ago, often without a single answer. Either my problems are so unique (quite unlikely when following an official tutorial) or it's my way of describing the issues? Or maybe nobody else bothers to share their problems and knowledge publicly anymore?
What struck me today was a misleading error message claiming that my API controller either had received too few arguments or it had been missing in the service container altogether.
Today I learned: if you do an API call to a development server of your local Symfony project and have an active Symfony Profiler, there is a response header called X-Debug-Token-Link which, if clicked in an API testing application like Insomnia, will open a Symfony Profiler page in the browser, that has all the log messages, stack traces, and code snippets of the source code fragments referred by those information, nicely formatted in your browser.
This is what it looks like:
There is a cute emoji of a ghost to remind us not to take things too seriously, and there is all of the information, helpful and unhelpful stuff alike, neatly sorted into tabs and accordion panes, with expandable context data, highlighted code snippets, and with different fonts and colors to make it fun and clear to explore.
You can also find the uncritical log entries showing you what is actually working so you can stop looking for the error at completely unrelated parts of the process.
In my case, it still took some more exploration, searches, and trial and error to find out the actual reason (a missing namespace declaration in the file, undetected by IDE linting despite using PhpStorm with the latest Symfony and Shopware plugins) and undetected by the build process or Symfony Profiler as well.
A Significant Commit at the End of the Day
By the way, thanks to Juicy for the Shopware community post proving that I am not the only person who got stuck due to this silly little detail.
But exploring, comparing, and double-checking everything, making sure to follow the guidelines and trying to make sense in my head without relying on tutorials and documentation, is - of course - the best way to really learn how and why things work and what to keep in mind when coding something similar next time!
Top comments (0)