Thread 106394454

Why do checked exceptions cause so much seethe? They are really no different from Result (Rust) or Expected (C++).
Remind me again why forcing users to handle exceptions immediately after they are thrown is bad?

>Gojeets and /g/ Cniles really love to claim Java checked exceptions are verbose while typing
if err != nil {}

>after literally every function call

>>106394454 (OP)
checked exceptions are unironically really comfy
they are just as expressive as Result in rust and also being forced to declare the possible exceptions a function throws is great self-documentation that doesnt require using javadoc or doxygen
even c++ used to have the throws clauses but they were removed because the dynamic exception syntax and mechanism sucked ass
i wish instead of removing them they just reworked them to not be ass

>>106394454 (OP)
exceptions are fine except for when the programmer has a skill issue, that's why they make so many people seethe, because they only want to code the happy path like it's babby's first program

>>106394454 (OP)
>Remind me again why forcing users to handle exceptions immediately after they are thrown is bad?
because usually you can't do anything about it at that point in the program, wrap it in a runtime exception and let the generic top level error handler create an appropriate response for the client. you only code the happy path for the most part and the code stays nice and readable. the code you posted is giving me aids though

>>106394540
>typing if err != nil {} after literally every function call
Not only is it really unergonomic but is actually worse for performance.
Exceptions and C-style goto error are faster because the "hot path" with no errors is separate from the error handling path. When you encounter an error, you jump away to a handler, which is likely in a different cold memory page, while the "hot path" stays in its own memory page and avoids fragmentation. Errors as values are slower because you do the handling right on the call site, so your compiled function has error handling interwoven with function code, and it fucks with the CPU's branch prediction.
See: https://cedardb.com/blog/exceptions_vs_errors/

>>106394692
The code I posted is just some random image I found off Google, could be from some durgasoft jeet tutorial for all I know.
>you can't do anything about it at that point in the program
If that is the case then go ahead sure, just forward the exception up the call stack until you can handle it, but in most well-designed applications that usually is just one or two stack frames, unless you are calling from external libraries in which they should just be handling those thrown exceptions internally for you

>>106394692
if that happens you shouldnt throw checked exceptions like IOException anyway
only throw them when you actually want them to be caught and handled immediately, otherwise you just defeat the whole purpose
you have full control over what exceptions you throw and you dont need to throw retarded exceptions when you dont need them, also the standard library only throws them in cases where cleanup is very easy anyway

>>106394695
thanks anon
never thought of this before

>>106394775
>they should just be handling those thrown exceptions internally for you
i mean, what should a library do when you ask it to read some excel file but the file doesn't exist? if the library is nice they wrap the IOException in an UncheckedIOException for you, but ultimately you'll have to abort the current transaction and return an error to the client. nothing the library can do here

>>106394828
>the standard library only throws them in cases where cleanup is very easy anyway
what cleanup is there to do in case of an IOException? you tried to read / write a file or socket but the operating system says no. retry has little hope of working, so the only thing you can do is tell your client that it's not possible to proceed. to do that, you need to transport that information back to the place where the client initially called you, either by tediously returning it as a value through every layer or automatically via exception. since you might not control all layers (e.g. if you are executing inside a stream callback) and you callback is not declared to throw checked exceptions, the only sane choice is to wrap it in a runtime exception

>>106394454 (OP)
Because niggers can't be trusted with declaring exceptions thrown. So now you have to get in line and check the return value

>>106394454 (OP)
what specific lines can err?
how do i add an error context to specific erroring lines?
how do i make things fully explicit if i want?
where are the (checked) exceptions in the type system?
-----
if my suspicions are right, this is just a competing pattern with "if err != null" in retard-maxxing, except exceptions will always be exceptionally retarded.
and the fact that you wrote "They are really no different from Result" presumably unironically tells of someone who enjoys retard-maxxing himself.

>>106394454 (OP)
The problem with checked exceptions is that they are fucking stupid. They miss the entire point of exceptions. The Rust and Go options are even worse. The C method is decent, but most people do it incorrectly too. Haskell is elegant stupidity emulating exceptions with monads.
Here are the facts about errors:
1. No one gives a shit.
2. If they do, they can't do anything anyways.
This is why exceptions are god-tier. I write my programs as if the dice are always in my favor. I do not have to give a shit about anything except what I am trying to do with no err != nil or try/catch cluttering up my vision.
I ideally have one try/catch that sits at the heart of the event loop. I handle all errors in one place, simplifying everything. There are exceptions to this. I do have some specific places where an extra try/catch makes sense, but the ideal is always one.
So if exceptions are God-tier, why are the checked ones stupid? They miss the whole fucking point. You are sprinkling nonsense all over your code for no fucking reason. The entire purpose of exceptions is to remove nonsense boilerplate so you may focus on what actually matters.
This is bullshit spewed forth from "enterprise" retards who never understood exceptions. They put a try/catch in every method and checked exceptions in the signature. They are now reverting back to error codes because of the hell they created for themselves. They will ruin that too because all problems with programming fall back to the giant pig pens of mediocre midwits putting months of work into changing the background color of dialog buttons.

>>106395507
>I ideally have one try/catch that sits at the heart of the event loop.
Try using a default exception handler instead. Yes, you sacrifice the worker thread. Big fucking deal.

>>106395138
>what cleanup is there to do in case of an IOException? you tried to read / write a file or socket but the operating system says no. retry has little hope of working
If only life was so simple. The low level of IO really is very messy indeed, and some protocols are damn awkward.
You need to care about failure modes whenever you deal with the OS. Yes, it's awkward, but that's because you're dealing with reality and reality has all sorts of ways of fucking with both you and your code.
Exceptions are one way of surfacing failures to the program. Except in C++, they're not the most awful way. (In C++, you're well fucked as implementors treat exceptions as poor country cousins.)

>>106395507
good post

my preferred error handling mechanism is expected, with macro wrappers that allow you to ensure a T or propagate the E up the call stack with 1 line. P0779R0 would add support for this at the language level so you could do
int x = try someAction(); // someAction returns expected

And if try fails then it propagates the error up. But we don't have it so macros are the best you can get. If you want no exceptions but not to have boilerplate everywhere.

>>106395507
I work on real time software and we have to deal with errors all the time that are not fatal. Usually it's just propagating a message to the user to do something, but occasionally they're recoverable. Using an exception to handle that feels heavy handed when I can just return a Result or Expected

>>106395924
You literally just reinvented Swift error handling, except with errors as values as a bullshit in-between
https://docs.swift.org/swift-book/documentation/the-swift-programming-language/errorhandling/
Honestly Swift does error handling astonishingly well. It's the fast performance and syntax of exceptions while still having the type semantics of errors as values.

>>106394454 (OP)
nigga that font hurts my eyes

>>106395959
Cool, one of the strengths of C++ is that devs can take the pieces that are useful to them to make their software instead of trying to force everyone to use the same technique. Now I just need this shit in cpp

>>106395507
>being forced to handle errors immediately is bad, actually

>>106395507
>The entire purpose of exceptions is to remove nonsense boilerplate
It's not, though. The purpose of checked exceptions is to make it explicit what things can be expected to go wrong when calling something.
>They put a try/catch in every method and checked exceptions in the signature.
This just sounds like projecting.

>>106395728
You can't get rid of all error handling, or at least don't want to, but you get the point.
>>106395941
Realtime is its own thing. There are no good realtime languages with exceptions. Most C++ compilers use complex exception-handling under the hood. You should be using state machines with defined error states.
For RESUMABLE errors where you have the information and ability to continue, the answer is obvious. Most errors aren't like that.
>>106396098
They are never exhaustive because they would be even more nonsensical if they were.
>projecting
Learn to read retard.

>>106394540
Relying on the tard that implemented the wrapper function a man wrote to throw the right error.
Also, never implemented one’s own function where you have to check and throw errors.

The absolute state rustards’ PHd thesis on “towards implementing a perfectly safe fizzbuzz approaching the performance of interpreted python”

>>106394540
Relying on the tard that implemented the wrapper around a function a man wrote to throw the right error.
Also, never implemented one’s own function where you have to check and throw errors.

The absolute state rustards’ PHd thesis on “towards implementing a perfectly safe fizzbuzz approaching the performance of interpreted python”

>>106396779
>>106396993
Thanks for more evidence confirming the anti-Rust stance is botted

what are you even talking about, who the fuck talked about rust? checked exceptions are literally java

>>106394540
Odin didn't solve this issue completely but they added keywords to deal with chaining that stuff up the stack, like or_return and having named returns

It's insane to me that Go rejected the recent proposal to fix this verbosity

>>106394695
>trust me i read this blog once
in reality, the truth is completely different

>>106394454 (OP)
Because they defeat the purpose of exceptions in the first place, which is to handle errors where they actually can be handled and not to litter error handling code where it isn't relevant.

>inb4 "it's always relevant"

>>106394692
>because usually you can't do anything about it at that point in the program
>wrap it in a runtime exception and let the generic top level error handler create an appropriate response for the client
There’s something wrong with your architecture if you’re encountering this. By doing this you’re also exposing low level implementation details to the higher level layers which should be completely agnostic to that. Errors are part of the API of a component. Only the component which uses an API needs to know about that API and how to use it. Don’t leak implementation details like that.

>>106394454 (OP)
so the methods can only throw one type of exception or do you need to include all possible types of thrown exceptions

>>106394454 (OP)
it's bad design. exceptions by design are for things you cannot anticipate.
if you expect something to happen it's no longer should be considered an "error", it becomes the part of program control flow.

>>106400263
essentially the checked exceptions are encourage to write code like this
void FizzBuzz(int i) {
if (i % 3 != 0) {
throw new FizzException();
}
}

for (int i = 0; i < 10; i++) {
try {
FizBuzz(i);
}
catch (FizzException) {
Console.WriteLine("fizz");
}
}

Everyone should just copy Common Lisp's condition system

>Programmers must be forced to handle every error
>Just like my safe (TM) functional code right here
>herp.unwrap().dee.unwrap().derp().unwrap()

>>106394454 (OP)
Java’s checked exceptions are a major source of frustration – they force developers to handle potential errors after every method call, leading to massive amounts of boilerplate try-catch code and significantly increasing cognitive load. While intended to improve robustness, this approach actually makes error handling cumbersome and often leads to developers simply catching and ignoring errors without proper investigation. Languages like Rust’s Result or C++’s Expected offer a much cleaner solution by explicitly signaling potential failures at the point of origin, reducing boilerplate and making error management far more straightforward.

Exception messed with the control flow, they told me.

>>106400323
elaborate

>>106400301
No one has ever written code like this, even in Java

>>106394454 (OP)
the problem is some exceptions are more special than others so not all exceptions are forced to be handled. it's unworkable simply for that reason alone.

>>106400380
Unwrap shouldn't even exist. It's retarded. Match expressions exist for a reason.

>>106401903
>Unwrap shouldn't even exist. It's retarded. Match expressions exist for a reason.
But they are used and abused for crabniggers to lie about their shit
let result = soy_out()
match result {
Some(x) => // ...
None => // ...
}

> :O

err := smash_rock()
if err != nil {
// ...
}

> >:(

>>106402109
.unwrap is far more ergonomic than if err != nil, but you are a poopjeet and you get paid 5 rupees per line of code so of course you prefer go benchod

I've never met anyone who disliked explicitly declared exceptions (like java). In fact, I wish C# or javascript/typescript had them

The problem with Exceptions is

>they interrupt the flow of the program
they can be thrown from virtually any line and so it makes it slightly more difficult to "ReAsOn AbOuT yOuR cOdE"
>they're slow, in some langs.
in C# exceptions significantly slow down your program, and shouldn't be used at all in hot paths. idk about java, js, or C++, but I'd except maybe the same
> They have their own scope, forcing you to something write code like
Foo foo; // uninitialized variable!
try {
foo = initFoo();
} catch(Exception e) {
return "error";
}


which isn't the worst thing, but can get verbose. The alternative is to just wrap your entire method in a try-catch which make point #1 more likely

Result patterns are just better in every way except you end up writing similar blocks of code like:

var fooRes = getFoo();
if(fooRes.error) {
return fooRes.error;
}
var foo = fooRes;


i.e, 5 lines of code to initialize 1 identifier

>>106394695
it's possible to implement trvival monadic error propagation as exceptions under the hood

>>106402639
>if err != nil is equivalent to .unwrap()
You are the jeet here, retard.

>>106402729
C++ exceptions are pretty poorly designed, they are essentially just a wrapper on top of setjmp/long jump compared to Java exceptions.
Throwing exceptions that are created on the heap is retarded though especially if the exceptions just get discarded right after they are handled, I wish Java designed exceptions to be stack-allocatable

>>106402928
>stackoverflow
>lemme just allocate an exception

>>106403079
>OutOfMemoryError
>let me just throw new OutOfMemoryError()
yeah i can play that game too

>>106403152
not an issue, on startup libc preallocates space for that exception, only becomes a problem when compiled with noexcept

>>106401903
disagree. unwrap is basically, technically it can fail, but the failure condition is generally misconfiguration or extremely pathological and may not be recoverable anyway.

>>106400323
>Everyone should just copy Common Lisp's condition system

Based, and really this should end the discussion.

Pic related.

>>106403510
How is this different from C signals? This is just SIGFPE.

>>106394454 (OP)
>They are really no different from Result (Rust) or Expected (C++).
That's not an argument. You get result types for free when adding sum types, which is something that many people want anyway. Why would you add exceptions, a whole feature that makes your language more complicated and harder to reason about, so that you can get results that are "just as good" as result types? It doesn't make any sense.

>>106402928
what if you need to return an exception?

>>106403680
use case?
exception factories?
never seen it

>>106394454 (OP)
For the same reason forcing people to have a class and a main is bad.
Like 99% of projects don't need one.
Yes real projects do but if you are working on a real project you don't care about that since you already know the language.

>>106405249
Is main() being inside a class really that bad? That sort of stuff can be easily abstracted away, Java 25 has a hello world consisting only of this
void main() {
IO.println("Hello, world!");
}

Everything is in an unnamed or autogenerated class, which is all you need anyway

>>106405249
>99% of projects don't need one
It depends very closely on what you count.
Also, lolnope, hype merchant.

why not allow throwing primitives like C++

>>106406486
literally zero use case for this, the only reason c++ allows it is because it has no class inheritance tree, so no Throwable extends Object to restrain throwing to

>>106401903
why bother? mental circlejerking?

>>106394454 (OP)
You can propagate errors. Uncaught exceptions result in runtime crashes.
Also error types self-document the code.

>>106403639
>harder to reason
what's so hard about cancelable asserts? C people use asserts all the time.

>>106409495
>bugs result in runtime crashes
and how is it bad?

>>106396098
>>They put a try/catch in every method and checked exceptions in the signature.
>This just sounds like projecting.
Not him, but I've been there. try/catch with empty catch block in every method, because the application must never crash. If there ever was an error it usually resulted in some form of corrupted state and the program was completely borked.

>>106400607
Restarts allow the library programmer to specify potential recovery strategies to use user. For example RETRY might be a restart for an HTTP client. Maybe you get a permission error trying to access some files, you could provide a restart called FIX-PERMISSIONS that the user might choose to use.
The restarts were originally meant for development in the REPL to ensure errors in long running processes are always recoverable, but you can make use of them in user facing applications too.

>>106399635
>you’re also exposing low level implementation details to the higher level layers which should be completely agnostic to that
the higher level wanted to do a thing, the lower level discovered that it's not possible. you can wrap every lower level exception at component boundaries, but all you are accomplishing is an endless chain of "caused by" traces. when diagnosing an issue, the developer will then scroll down all the way to the root cause, ignoring the bullshit "caused by" chain. might as well not have it. sounds nice in theory, is just noise in practice

Checked exceptions are a psychological toll on developers merely because jeetvelopers fail to comprehend the value in treating the list of exceptions a function can throw as part of its signature or return type, they just see it as a chore to tack on as opposed to Expected which people simply accept that E is just part of the return type. This creates instances where jeets are more than happy to wrap all their code in .unwrap() and then match Ok() and Err(), but whine "what the hell, stop being a dick, compiler" when they did not list a checked exception or catch it and just instead swallow it by putting it inside an empty catch block or wrapping it in a RuntimeException. After all, jeets always look for the quickest way to produce the cheapest code, quality notwithstanding.

>>106394454 (OP)
>forcing users to handle exceptions immediately after they are thrown is bad
Literally the whole point of throwing things is to be able to walk up the WHOLE call stack. The point is to be able to return to any relevant catch block (ie: to multiple locations). Anyone who thinks you must catch every exception right where a function that throws is called is an idiot

>>106412269
then use RuntimeException when its appropriate
IOException has to be caught immediately for good reason, because it doesnt make sense for it to travel up the stack to nebulously or potentially be caught maybe later in the call stack, especially when checked exceptions represent common occurrences that can happen in a reasonable program, unlike something like NullPointerException

>>106409787
try/catch in every function call is just tremendously more expensive

>>106412257
>the value in treating the list of exceptions a function can throw as part of its signature or return type, they just see it as a chore to tack on as opposed to Expected which people simply accept that E is just part of the return type.
This is my issue with exceptions. There's an entire half of the code path that Cnile culture is to pretend doesn't exist. Designing and writing a program gets much easier when you're forced to think about all the things that can go wrong.

>>106400301
using exceptions for control logic is an anti-pattern
luckily, the only scenario this ever happens is when non-programmer highschool teachers try to teach programming and just follow some retarded course script (also made by a non-programmer)

>>106395507
the point of checked exceptions is that you know upfront that if some exceptional event happens, this specific exception will be thrown
knowing the possible errors upfront lets you better decide when to handle them
it's better than if every error were a runtime surprise - in which case defensive try-catching everything would be much worse

>>106413872
>knowing the possible errors upfront lets you better decide when to handle them
>it's better than if every error were a runtime surprise - in which case defensive try-catching everything would be much worse
true in theory. in practice you'll handle everything the same way: roll back current transaction, inform client with generic error message. it's rare that you can do better