My pet peeve from Java EE is the “stack trace from hell”, when the app server shares its pain with me, showing a stack trace, instead of telling me in which source file I messed up some setting. Oh goody—I just switched my Android build to Gradle, and it acts the same way. Hello, dev tooks makers. If you can't trace back your failure to the file name/line number of my artifact, you have failed.
6 plus ones
Shared publicly•View activity
- Thank you for this enlightening series. It really made me aware of shortcomings of my own development style.
I am working on a project that introduces JSF-style templating to PHP Zend Framework for the purpose of getting out of <div> soup that most PHP templating engines are. During development of XML DOM parser I had some cases where I would get long stack traces when particular template feature was not implemented yet. I would then write a Unit Test for that missing feature and implement it. Now that I have read your posts I realized that those same parts of code would still throw those unmanageable stack traces if I ever forget exactly how the template engine suppose to work or even make a basic typo when I start using it in real projects or release it as a framework module to the public.
Making error handling as an after-thought is difficult, so I will go back to ensure I can generate a meaningful error in all unexpected cases before the codebase grows too complex.Dec 17, 2015
- That's one thing I love about SBT recently. The config files are actual Scala code, so you can figure out if it doesn't compile pretty easily. Now, if you have to modify SBT, that's a completely different story.Dec 30, 2015