Ranter
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
Comments
-
So the existing implementation can throw an exception that is also handled inside that exact implementation in a shitty unusable way?
-
@Rikan the hell, isn't the point of an exception that it is handled in the code surrounding it? What are these people thinking? This sounds like madness, how are those errors handled in other parts of the system?
I could only justify it in a functional programming way with Either -
Rikan2836y@alexbrooklyn the whole platform ist written by people without any experience and common sense. In this case, they basically pray that no error occurs and they don't have to edit the resulting database entry.
But what do I expect from people who write classes with over 8000 lines and only static methods -
Sounds like my kind of place. Here's to hoping you have static classes with cyclical dependencies on each other
Related Rants
Had to extend the platform of a customer. For one part of my task (generating an encrypted string) there already was a class with encryption and decryption methods. This class is used in a gazillion places all over the code, so I thought it might be a good idea to re-use already existing stuff... Until I saw that the encryption method using basic Java methods (all fine with that) wrapped in a try-catch block, 'cause the Java methods may throw, returning err.getMessage() in the catch block...
Yeah...sure...makes sense... Instead of throwing an error or returning null just remove the possibility to handle the error.
So I decided to basically copy the methods and return null so I can work with that.
Created a merge request and was told by another dev of that company to remove my own impelemtation of the encryption method and use the already existing. Arguing that I won't have a possibility to prevent my code, that returns an URI containing the encrypted string, from generating something like "http://..../Encryption failed because of null" without success.
So I had to use the already existing crappy code...
rant
java
no error handling
try-catch-fail
legacy code
encryption problems