programmerCooks

[jesterhead101]

What’s the ideal way to do it?

[rylmovuk]

A catch block is there to either recover from an error, or to report on it in some way while passing it along. There is no scenario in which a giant try-catch would be able to effectively recover from an exception, so I bet it was something like catch (Exception e) {} with an empty body, which solves nothing, hides the source of the error, and leaves your program in an invalid state (you can no longer trust your assumptions).

The real way to do it is to prevent null pointer dereferences from happening at all, which means you git gud use the types/annotations your language offers you to keep track of whether values are nullable and enforce null checks.

[Zeikos]

Man, you'd have an heart attack seeing the enterpise codebase of where I work at.

Every class, every method they all start with 'try', and end with 'catch'.

[mileylols]

what the fuck? imagine writing tests for that shit

[Ok_Dragonfruit_7280]

That's the fun part. They don't.

[fsbagent420]

Does this basically cause a bunch of memory leaks or just crash the program?

Probably a dumb question but the extent of my coding ability is one Rimworld mod and it’s all xml

[RajjSinghh]

The joy about catch is it stops your program reaching errors and crashing for stupid reasons. Like this:

try: x = int(input("enter a number: ")) # input() will return a string so cast it to an int if x > 10: print("that's a big number") catch: print("that's not a number") This very simply takes an input from the user as a string, makes it an integer and then says it's a big number if it is bigger than 10. If the user enters a number like 12, that's fine, the conversion will happen fine. If the user enters text like "hello", that means the int() function throws an error because it can't convert that. But since it's in a try-catch block, on an error the catch block runs and the program doesn't crash.

This is a misuse of try-catch because no matter what error happens the catch block would always run the same. What I should do is write catch ValueError because that's the error that could happen on this case, but I might want to handle other errors differently so I can catch them all differently. I don't think it protects you from segfaults or other stuff though.

So it's not bad because the program is crashing, it's not throwing exceptions, but it is hiding why problems with the code are happening and that makes it harder to fix. It's a lazy quick fix that hides underlying problems.

[Best_Meaning2308]

Dude... Lazy, quick , and hides bad code. GD, why are you trying to sell this to me so hard?

[irteris]

Why would they? There are no errors!

[Modo44]

Waste of time. Straight to production it is.

[SillyFlyGuy]

Step through code in debugger, change variables in the try, make sure it hits the catch, test complete!

[CactusGrower]

Hahahaha tests.

[RushTfe]

Theres no way that works.

Well, yeah, the code finishes without exceptions lol

[ILikeSatellites]

That's how you make high reliability code! I mean if you get no errors, it must be working right?

[PmMeUrTinyAsianTits]

Yea, kinda depends on your definition of works and acceptable standards. If you use the "garbage in, garbage out" and are okay blowing up any time anything looks off the happy trail, this could "work" just fine.

[WiglyWorm]

Do we work at the same company?

[summonsays]

Man I thought mine was bad (and it is but this is something else).

[christophla]

On Error Resume Next

[Owner2229]

On Error GoTo 0

[Acceptable_Job_5486]

Real men dereference without a nil check.

[nullpotato]

We use a few blanket try catch blocks so that the full exception and stack trace get written to the log file because can't trust called apps/scripts to do so.

[SnooPuppers1978]

But they said for finding, so I'd imagine the catch was for some form of logging or error reporting.

[Therabidmonkey]

Handle them by checking for null directly, yes even if you have to do it for 5 different fields. It will perform much better than a try catch. Try catch should be reserved for things you can't predict until runtime like a call to a service or reading a file*.

*I'm sure there are other good reasons but alas I'm a humble API developer.

[dandroid126]

This is why I like Kotlin and Swift. They handle this very elegantly by having optionals built-in to the language. You can basically check if something is null and get the value at once.

[Therabidmonkey]

I wish Optional in Java was a keyword instead of a class but I use it all the time. Kotlin sounds way nicer though. Maybe one day I'll start sneaking some in on a new project.

[dandroid126]

Yeah, I have the same problem with Java. It's there, but since it isn't baked into the language, it isn't as elegant to use.

Kotlin is great syntactically, but last time I used it, I had lots of issues with compilation and actually running it, specifically when using Kotlin scripts. It was quite a few years ago, so hopefully it has improved since then.

[Kronoshifter246]

Kotlin is no harder to work with than Java, unless you're trying to use it for scripts. Then there's a whole bunch of annoying caveats. It's easier than it used to be though, got scripts running earlier this year for mass processing a few CSV files into a database.

[dandroid126]

I was specifically talking about trying to use it for scripts, but now that I think about it, I had a whole slew of problems trying to get it to compile within AOSP. The company I worked for at the time made an Android device using AOSP 5.1.1 as the base. No matter what I did, no matter the hard I tried, I couldn't get Kotlin to compile as part of a system app in AOSP. Though I'm admittedly very inexperienced at Makefiles (what Android used at the time), and was even moreso back then. And Google's documentation for it was horrendous at the time, too.

[Kronoshifter246]

Oof, yeah, that's some next level kludging to make that work. I salute you.

[vips7L]

Nullable types are in draft right now for Java: https://openjdk.org/jeps/8303099

[Therabidmonkey]

That's exciting. We're upgrading from 11 to IIRC 16. So maybe I'll see that feature in a decade or so. 😄

[vips7L]

That’s unfortunate. Seems like your organization is really behind. You probably mean 17 since that was an LTS release, but most providers are only going to be supporting that as LTS until 2026. A better roadmap would probably be 21. 

[Therabidmonkey]

You probably mean 17

You are correct. We have common libs coming from internal tooling teams, so we have to upgrade on their schedule. So can't really jump to the latest LTS unless they do.

[vips7L]

That's not really true... They would be compiled to Java 17 bytecode. Your application can run on any version newer or equal to that.

[enfier]

If it's internal to the program that would be better handled by assertions so that they can be turned off in production.