try (HappyHolidays happyHolidays = new HappyHolidays()) {
happyHolidays.wish(all);
} catch (HolidayWishesNotWelcomedException){
specialCasePatternInterface.specialCaseCall();
}

Yep.

Java sucks.

There you go
@highlight
try (HappyHolidays happyHolidays = new HappyHolidays()) {
happyHolidays.wish(all);
} catch (HolidayWishesNotWelcomedException){
specialCasePatternInterface.specialCaseCall();
}

Or if you dont have brain damage and use recent java

@highlight
try(var hh = new HappyHolidays()){
hh.wish(all)
} catch (Throwable e) {
//No
}

@tekashi

*loud screaming*

@tekashi That's not clean code because the 'hh' variable name is not clear.

@Cultist Based on what arguments?

@PrivateGER Why?

@tekashi Let's not forget by using Throwable you're unnecessarily occupying the CPU pipeline too much. Now that's brain damage. It would also be of use if you wouldn't insult people but rather be constructive.

@tekashi Moreover, var is also bad practice and unnecessary use of system resources.

Nobody was talmbout clean code, but i dont remember it defining one-use throwaway variables with 60 col names.

Id like to see citation on var and throwable using more resources.

@CaptainRant That whole thing is so incredibly verbose, it makes me want to vomit.

@PrivateGER Right, but what we learned at the top university in our country is to introduce verbosity. It makes code professional - I mean, look at the Spring framework. It's often you see names like ThrowableBusinessAdapterPatternSpecialCaseClass. In the book Clean Code it is mentioned that you should completely elaborate and make your variable names long - because making them ultra short isn't helping anybody.

Even my colleague says it: it's pretty asocial of you to write short code because your teammates too have to understand it. I'm often asked to write a bunch of if statements rather than to shorten them.

@tekashi Well, I'm afraid you would have to pick up your book on Systems Engineering from uni to look that up. We've all had that class and I'm not re-iterating basic knowledge.

@CaptainRant okay since you are just full of shit let me educate you

Type inference is done compile time, which might slow down compilation, but in jvm bytecode any types dont exist, so the runtime performance is the exact same as explicit types.

Type casting, while might have performance drawbacks, it is only relevant when downcasting (and is highly optimized since the collections fw uses it heavily), but in this case, upcasting takes no time since subclasses can just overwrite super class memory addresses directly, and ram modification is fast on the jvm.

While im at it, this has absolutely nothing to do with system engineering, its a simple architectural problem, something you would have learned if you gave it any effort instead of thinking your 2008 college textbooks cover any useful information, making you stuck on java6.

@CaptainRant There's a fine line between using x as variable name and writing a god damn novel. I admit your rant example isn't too bad, but Spring has made me want to vomit often enough.
Find me a single human being that can possibly remember any of these class names and I'll accept them, but ThrowableBusinessAdapterPatternSpecialCaseClass is an absolute abonimation.

@PrivateGER Haven't you read the book Clean Code? It says there that the point of clean code is to make it so that your code reads like a novel. We're humans, not compilers. Your code should tell a fluent story.

Here's an easy pick from Spring: SimpleBeanFactoryAwareAspectInstanceFactory . Despite the class names being long, as long as you understand the concept an intent behind them, they're not that hard to remember. It's the same like in high school you had to remember Pi to 300 places; it's long, but as long as you have a system and understanding, you can remember any length.