Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
I agree with this 1000%
If you call a function that CAN raise an exception or return an error code and you don't handle it, You're making shitty software.
Most people only want to design and build what a system does when everything goes right. Engineers design systems that fail in known and safe ways.
Design and code the sad paths you goofs. Fuck what you're manager says to do, do it right. -
"oh this index should never go out of bounds"
"this mapping should always have this key"
"They would never give me a non ASCII encoded string"
"This dynamically typed variable will never be null or undefined so it's safe to always call a method on it I expect to be there"
And other nonsense you tell yourself -
In JS and C# there is no compilation error or even a warning that you forgot to catch an error that might be thrown. This is bullshit by design!
That’s why the choice of the programming language matters!
Kumbaya devs will say that it’s much more convenient to have no compilation errors and that they will make sure to not forget to check it manually. But we all know that this is bullshit. -
@kiki this mentality is very worrying.
-
@kiki agree
-
@Lensflare AII good so far, ten years and counting. Whatever app you work on now, if it's a real gig with multiple programmers, has just as many bugs as mine. If so, then aII the time you spent on fancy error mitigation was for nothing
-
@Lensflare I worked on software with government involved. We were not allowed to give a db user access rights for certain object until we got error. Sick huh? We documented errors and gave access then
-
@kiki @retoor just because it’s a viable practice, doesn’t mean it’s a good one.
What would you even take as an indicator for when it doesn’t work? Of course it works. But it’s full of bugs and silent fails. Until you find out by chance that there is a problem, many users already had their data corrupted or something not working, either without them knowing, or without you knowing.
I know that not all bugs can be prevented and you often need to wait until they happen, but when we are talking about that level (topic of this rant), it is completely preventable and it practically doesn’t need any effort (depends on the language). -
@Lensflare > "just because it’s a viable practice, doesn’t mean it’s a good one."
Amen.
I'd been the one trying to figure out crashes, random data issues, etc, then to find the developer either 'ate' the exception, logged a generic "An error occurred" message (with no context), or caused side-effectual behavior (didn't check to see if a returned value was null and updated a field with bad data).
So over time, I developed our logging strategy that freed the developer from making decisions about what data bits were important and making it difficult to 'get around' the logging system.
Attached is an example of data we log to Splunk.
-
@kiki > "If so, then aII the time you spent on fancy error mitigation was for nothing"
+1
Defend against what you know will likely happen (nulls, exceptions other code throws, etc) and log the rest. Then from those logs, tweak/re-factor as needed.
I can't find it right now, a developer tried to push the idea that exception handling was a mechanism for business logic flow. In a lot of his code, there were more lines-of-code in the exception handling ('fancy error mitigation') than the actual method.
Example
try
{
// 10 lines or so of database access code
}
exception
{
// 50+ lines of code, calling other functions, etc.
} -
This is funny. Because in Qt they fucking can't handle exceptions (I think they are turned off). Something to do with not being able to guarantee state or some shit. So if it encounters one it just segfaults.
While when I was programming Python I eschewed checking for error conditions and just let exceptions catch all the bullshit. To be honest I liked Python's approach. Supposedly that is the Pythonic way. I dunno. One thing I really liked about Python was if you had an exception it didn't just kill the app. I found code that was producing exceptions on exceptional data in the logs. Sometimes years later. I really like those logs. -
Also, the C++ compiler throws warnings. We have some projects at work that throw thousands of warning during compile of the project. We "know" we should be addressing those, but there isn't money for that. So it just is getting worse. Some of those warnings are because functions are getting removed later. Eventually we will have to fix those at lest. On new projects I try and make sure there are zero warnings on compile. I think in long run it saves time.
-
@Lensflare Lack of compilation errors is why I've gone to religiously using typescript.
Sadly there still isn't any modifier to a function like "function xyz(): number, throws <some error>"
I'd be delighted if that was a thing.
For now I can only pray for a jsdoc comment mentioning a possible throw. -
@Lensflare In VS you will get warnings if there's a potential null reference happening and they have what they call null state analysis which existed before but was enabled by default from .NET 6. As for warnings about everywhere a potential error might be thrown.. 🤷♂️ There are pros and cons, I am not one for being babied too much but at the same time getting good habits forced upon you is not bad either.
You can write good, solid code without having to handle every unlikely and possibly never occuring incidents. There's a balance. Be pragmatic. -
@devdiddydog language design and std libs is the problem here, really.
If the language allows any function to throw and if the std lib contains functions which all can potentially throw, then it practically forces you to be pragmatic, because otherwise your could would be buried in countless try catches.
Also, it doesn’t help that Exceptions and throwing is the only means to indicate errors and handle them.
Bad language design forces you to compromise on safety (regarding bugs). -
@Lensflare what are some examples of well-designed languages in your opinion?
-
@kiki Swift does it particularly well. Functions which can throw are explicitly marked as throwing. The compiler forces to catch a throwing function (or to rethrow), when called.
The std lib uses various methods for error reporting, based on what makes sense the most. So, only a small set of functions is actually throwing. -
@Lensflare hmm… interesting
-
@lungdart
"What's the worse that could happen? A segfault? In an airplane? On the flight controls manager's unit firmware? Where 300 people could die? Fuck me..."
Joking aside, the required focus on error handling really depends on what is product being deployed I believe. -
@Lensflare yeah.. But is throwing exceptions not more framework stuff instead of business logic? It's kinda weird to throw exceptions if you know it's possible. It means you allow flaws in business logic. It's a complex subject
-
@fandi Swift has this
Related Rants
Stackoverflow.
Amen :p
Such a relief
No one fucking knows how to handle/raise errors.
I feel like this is the least talked topic in all fucking programming industry. This shit needs to be tought even more than the fucking SOLID, DRY, KISS, YAGNI and other kinds of buzzwords that fancy devs love tossing left and right.
Basically everyone just does "whatever you dumb error just dont bother me". They will just log/return null/ignore the errors and be in their oblivion with bugs propagating upstream the call stack.
"Throwing errors you say? Ew, why do you want to produce more errors?". Yeah, right, just stick another log/return null/or ignore the fact that the monke calling your function with bullshit arguments.
"But bro it's so difficult and time consuming and it would never happen!" Yes, you fucker! Yes! Programming IS fucking difficult if you want reliable systems! Did you not know that!? Well now you do! Go and fucking learn it!
FUCK!11!1!!
devrant
exceptions
errors