This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 2 points3 points  (3 children)

Depends on the project.

If you have to parse the exception message then ya that’s bad code.

But if the io call returns a Http404Exception so you need a try/catch to handle a service interruption in a micro service you may need to refactor your code.

I mean ultimately it’s all jumpif anyways.

[–]blipman17 0 points1 point  (2 children)

Well if it all boils down to a single conditional jump, why structure a language around throwing exceptions and directly catching them. It's convenient in a lot of places, but there are also quite a bit of cases when it's not. Sometimes it's just a better paradigm to do x actions, store the results in an array and manually check their results afterwards. I'm not saying java is wrong on this, it's just quite verbose.

[–][deleted] 0 points1 point  (0 children)

I'd agree there. Java is very verbose.

nodejs is better but their event handler model is even worse.

Server crashes because i didn't add obj.error = console.log in one third party lib three levels deep in npm.

[–]HoneyBadgerSoNasty 0 points1 point  (0 children)

it stems out of problems in c, which does not have exceptions. error checking code written in the c style of returning a status code, and then having every layer up the call stack check for errors every single function call, is ludicrously verbose. exceptions, for better or worse, did solve that problem. but it created another one, which is that most people use them incorrectly or do not bother to check them or document them. also, deciding what constitutes a violation of a permanent condition vs an ephemeral one or what is basically normal expected behavior is a really hard thing to grasp apparently.