You expand your knowledge in useless things like design patterns and frameworks. Odin will make this type of knowledge useless.
Making simple tickets to epic shows that the company does not have a software architecturer. It means that you create a monster application with full of technical debts left by junior. If CDD used in your company, nobody would ever be able to replace a ticket with an epic, because the architecturer would show you from where to start and what steps to take.
System administrators are paid to wake up at night to fix things.
Ask your boss, "do you want your users wait until the next morning for the system administrator to wake up and fix the issue? Or do you want the software inform the user how long it will take to fix the issue in seconds and start calling the system administrator to wake up and fix it?"
Because you answer based on your preferences as a worker who wants to avoid the extra work to make the system perfect and not your boss's preferences.
The “while doing it” does not work if you don't have experience with similar language.
If you don't believe me, try learning Rust while writing a server for your work.
Tickets are useless. Real tickets are unit tests that need to pass for the software to be ready for production.
Tickets cannot protect you, only Odin's switch statement on stack trace can protect developers from bad changes.
I will give you an example, you worked for a company and on a ticket, you wrote “this code works this specific way and should never be changed”. After 6 months, the company fires you and another senior developer takes your place. The new developer never read previous tickets because no one read old completed tickets, so no one will read the message you left, and they will change the code accidentally.
However, in Odin with unit tests and locking stack traces with switch statements, the code is really protected from these kinds of accidents.
No, you don't need to just log and return 500, you can make the software to handle these kind of errors.
You could make the software call the system administrator and return a message to the user "Try again in an hour, the system administrator is fixing it now"
Or if it is a timeout, the software will call amazon to buy a new machine to scale the database and send a message to the user "Try again in an hour until we scale the system".
Developer's job is to automate error handlers and not be the error handlers.
If you can see the stack trace tree, then you can plan far ahead, but to do that we need to destroy this "agile" mindset, that is always in a hurry and doesn't let you to think that far ahead.
Odin's way does not mean that you have to do something for every Exception that is thrown to you.
Also, in Odin SQLException can not exist, it is too generic, but SQLClosedConnException which is more specific can give a different story to a stack trace, which you can handle.
For example, in Authentication_Filter_Error union, you will have another union called SQL_Verify_Account_Error, that it will contain SQL_Error enum with the Closed_Conn value.
Imagine your stack trace like this Authentication_Filter_Error -> SQL_Verify_Account_Error -> SQL_Error.Closed_Conn
Now when you know that can happen (through CDD), you can create a switch statement to catch the specific stack trace, to call the system administrator in the middle of the night to check what happens.
This is how software should handle its errors and there is not even a need to log it.
In your scenario, you wake up, you go to work, everyone is screaming at the office, you check the logs, you see the problem, and then you call the system administrator for the problem.
Look, you are very lucky for sticking with java and using your OOP knowledge to move to other programming languages.
But an unexpected change will come and you will need to go back studying on your free time.
This is always happening in our industry, you were just lucky for not living it because you sticked with Java.
Your system with Java will break if someone else add an AuthenticationFilter, but my system in Odin will not even compile until I have handled all the stack trace paths that include AuthenticationFilter.
Do you see the differences between handling stack traces with union types rather than string?
So you telling me that you don't need to study on your free time? Is that correct?
You can't program in any language, don't fool yourself.
Take, for example, SQL that is used in all companies. Can you write SQL functions with the same ease as Java? You may ask why do you need functions in SQL? Because it is faster to run the algorithm in SQL, rather than in Java from an ORM.
When you try to implement it, then everything on what I said will make sense to you.
Also, we don't need log systems when there is a programming language like Odin to parse stack traces with type checking (not just string like you gave me as an example from Java).
In microservices you are the error handlers. For example, if in the logs you see a stack trace, then you will go to the code and fix the error.
In Odin I don't need to go in that trouble, because ALL the stack traces can be handled. There will be no undefined behavior in software or unexpected input that caused an unexpected stack trace, so there is no reason to have logs.
First, in the article I wrote how detrimental it is to the developer's social life, to know multiple languages.
Secondly, companies need to realize that they request multiple programming languages because the current programming languages can't parse stack traces, and they push everything to microservices, so they can parse their errors from DevOps services. Which means they don't request only to know multiple languages, but also DevOps services.
For some “can't” statements, you don't need to write any error.
The “can't” statements in CDD are for actions and input that you could take, but the software deliberately prevents you from doing them.
There are no actions or input, requested from the exercise that make it possible to do the list you gave me, so it does not make sense to create an error for them.
I put coloured glasses on the past because back then companies didn't request developers to know more than one programming language. They just used fancy words for simple tasks.