[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vm / vmg / vr / vrpg / vst / w / wg] [i / ic] [r9k / s4s / vip / qa] [cm / hm / lgbt / y] [3 / aco / adv / an / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / pw / qst / sci / soc / sp / tg / toy / trv / tv / vp / vt / wsg / wsr / x / xs] [Settings] [Search] [Mobile] [Home]
Board
Settings Mobile Home
/g/ - Technology


Thread archived.
You cannot reply anymore.


[Advertise on 4chan]


File: java.jpg (203 KB, 3840x2400)
203 KB
203 KB JPG
Forced exception handling is one of Java's best features and I'm sad it's not a thing across other languages.
>>
>>102444070
>just interpret printf return status bro
>>
>>102444070
Why does Pajeetsoft C# not have this?
>>
>>102444070
give me structs for java 24 saars
>>
>>102444070
Once Java gets value types it will be based.
>>
So many midwits shilling for checked exceptions this week. What gives?
>>
>>102444070
>Until a dev catches it and throws a runtime exception
Well there goes your precious checked exception bruddah
>>
>>102445386
>pretending to not know th3o.gg or the primeagen
chat is he cap?
>>
>>102445098
> Why does Pajeetsoft C# not have this?
because we are not paid by lines of code and tend to use indoor sanitary facilities
>>
>>102444070
Exceptions are a bad idea, it's goto all over again.
>>
>>102444070
>Forced exception handling
It's not true though
You can just say throws ... and it all goes away
>>
because the idea that you can "handle errors" is a dangerous illusion that may cost you subtle bugs, because you are swallowing exceptions/errors instead of reporting them.
>>
>>102445386
https://www.reddit.com/r/programming/comments/1fdow27/why_i_prefer_exceptions_to_error_values/

https://www.reddit.com/r/rust/comments/1ffz3fn/rust_error_handling_is_perfect_actually/

it's funny to read these side by side
>>
Supervision trees in Erlang are the best way to handle errors. Actually Elixir is the best language to built reliable servers.
>>
>>102444070
>Forced exception handling is one of Java's best features
sure, but the fact that you can use both checked and unchecked exceptions is retarded
>>
>>102444070
Doesn't it take a ton of cpu cycles to catch and handle an exception instead of having errors as values?
>>
>>102445098
because it wasn't made by retards
>>
>>102445098
https://www.artima.com/articles/the-trouble-with-checked-exceptions
>Anders Hejlsberg, the lead C# architect, talks with Bruce Eckel and Bill Venners about versionability and scalability issues with checked exceptions.
>>
>>102444070
Forced exception handling is the dumbest Java feature. It's the worst of both exceptions and proper error handling.
>>
>>102444070
Based.
People who hate checked exceptions really just don't understand them. Just like memory management in Rust, if you handle your exceptions when they happen your shit code won't crash.
>but I don't want to handle IOException at the place I make a network request
Great, wrap that shit in a domain exception and pass it to a layer in the code that gives a shit. I hate when I'm writing code and I have to figure out the runtime exceptions something throws from the Javadoc or find it by experimentation.
>>
>>102449370
i always wanted to know. what do people like you write inside catch block?
>>
>>102448820
It is heavier than returning values, if anything it's because the exception also carries the whole stack trace of each class and line of code
But if an exception occurs, you shouldn't really be on the "must be as fast as possible" path anymore. It's in the name - exceptions - they're not meant to be used to control normal program flow. So the difference in performance shouldn't matter in practice
Also exceptions are easier to find and follow in the code than error return values mixed with normal return values
>>
>>102449904
catch(Object o)
{
//do nothing
}
>>
>>102449904
Lifted right out of ChatGPT, more or less.
With checked exceptions, you don't have to figure out what the call can throw, and you don't need to catch everything everywhere either.
public class NetworkService {
public DataObject fetchData(UUID dataId) throws BusinessException {
try {
URL url = new URL(urlString);
HttpURLConnection connection = (HttpURLConnection) url.openConnection();
connection.setRequestMethod("GET");
//connection query parameters and whatever else
// Check the response code
int responseCode = connection.getResponseCode();
if (responseCode == 200) {
return new DataObject(); // Assume you did XML or JSON or whatever the fuck parsing and constructed something useful.
} else {
throw new BusinessDataException("Failed to fetch data: Response code " + responseCode);
}
} catch (IOException | XMLException | JSONException e) {
// Everything from NXDOMAIN through timeout errors are children of IOException.
throw new BusinessDataException("Could not get data from data service.", e);
} catch (Exception e) {
// Handle other checked exceptions as needed
throw new BusinessDataException("Something fucky happened getting data, and we didn't think we would get this exception.", e);
}
}
}
public class DoShitService {
public void doShit(UUID dataId) {
try {
DataObject data = networkService.fetchData(dataId);
// do shit with data
catch (BusinessException e) {
LoggerPackage.logShit("We couldn't do shit.", e);
// If not doing shit is crash worthy, either throw a new RuntimeException or start calling System.exit() and whatever. Otherwise, do nothing.
}
}
>>
>>102449370
>People who hate checked exceptions really just don't understand them
Be real for a second. It's obvious that there are more people who prefer exceptions because they don't understand "monadic error handling" than people who prefer "monadic error handling" because they don't understand exceptions.
(Specially since monads also allow for try-catch style error handling).
>>
>>102448936
there is a good argument that error handling and resources cleanups are different things. maybe that's what people mean by "error handling"? resources cleanup?
>>
>>102450834
>catch (Exception) {
throw new Exception()
}
>>
>>102444070
throw new RuntimeException(checkedException); // not my problem
>>
>>102450834
don't wrap your exceptions like that. it's a footgun waiting to fire.
for example you may wrap something like null reference exception in BusinessDataException and somewhere up the stack you may decide to swallow it, because it looks like a sensible thing to do, because as the name implies it's just some business logic related exception, nothing critical.
>>
>>102448936
>I'm a strong believer that if you don't have anything right to say, or anything that moves the art forward, then you'd better just be completely silent and neutral, as opposed to trying to lay out a framework.
C# is based wtf
>>
>>102444070
>uh sweatie there could be an unhandled jsonexception ther-
try/catch (aka shut the fuck up)
>>
>>102452775
>you may wrap something like null reference exception in BusinessDataException and somewhere up the stack you may decide to swallow it, because it looks like a sensible thing to do,
Imagine a parsing library threw an NPE because some field in some service was null. That can and does happen, all the fucking time.
That would wrap as BusinessDataException caused by NullPointerException. The stacktrace would indicate the line number where the parser died and then it can be fixed.
The caller can't do anything else if it did eat the NullPointerException directly, because there's nothing useful that will return from that method call once that happens. The caller can't restart the parser, the only thing it can do is call again and get the same result.
As long as the stacktrace isn't lost passing the exceptions around, which is a coding error, it's the best way to handle something like that.
>>
>>102454697
people usually define custom exceptions like that precisely because they want to catch them and do something other than logging, otherwise there is no reason to just wrap exceptions and rethrow them.

>The caller can't restart the parser
why would you want to restart a parser routine after NullPointerException. if that's a server request handler, you just terminate request and return error code.
>>
>>102447100
Then your architecture team is doing something retarded
>>
uhhh.. isnt that how exceptions work in all languages



[Advertise on 4chan]

Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.