Thread 106124169 - /g/ [Archived: 439 hours ago]

Anonymous
8/3/2025, 8:55:47 AM No.106124169
u70133cuzq211-2576096037
u70133cuzq211-2576096037
md5: d17eab1eaf0473329035931854b73b6c🔍
You guys are missing the point of exceptions vs errors. Exceptions are nice for when I have no idea what kind of error's gonna happen, I want to catch it and send it to Sentry or Datadog and tell a user "sorry". Happens all the time in webdev and I've rarely ever seen anyone using Exceptions for anything else. Errors are a way for a function to tell you it cannot proceed, it is literally like returning null in a duck typed language where you can return whatever. So really not an actual error, but more like a signal that a function couldn't compute. So you ideally want both mechanisms. But more importantly, you want to write code with minimum amount of explicit error handling, because it's retarded to have both try/catch or err != nil be half of your codebase. Don't be a retard.
Replies: >>106125100 >>106125466 >>106125617 >>106125948 >>106126004 >>106126071 >>106126166 >>106126342 >>106126436
Anonymous
8/3/2025, 9:49:00 AM No.106124471
Explicit error handling is good.
Anonymous
8/3/2025, 11:36:54 AM No.106125080
Just post in /dpt/, it's at least bumped regularly.
>don't be retards
Nooooo!!! The code is inherently insecuree! You internal a + a method is going to get a string argument from user input, so you MUST check that the argument is a number, and throw shit if it iss!!!
Anonymous
8/3/2025, 11:39:33 AM No.106125100
>>106124169 (OP)
>rarely ever seen anyone using Exceptions for anything else
The absolute state of weblets.
Anonymous
8/3/2025, 12:46:51 PM No.106125414
exceptions fucking suck in every form and the instability of the average python/java/ruby/c# project even after decades is the proof in the pudding
Replies: >>106125510 >>106125987
Anonymous
8/3/2025, 12:55:37 PM No.106125466
>>106124169 (OP)
I saw in an old dotnet framework web api where exceptions are used as flow control when logging in a user and generating the jwt token
Replies: >>106125532
Anonymous
8/3/2025, 1:01:47 PM No.106125510
>>106125414
What do you mean instability? I work with Ruby, among other things, RoR is literally the most advanced, stable and secure web frameworks out there. I hear Django is pretty good too along with whatever the have in C#. I don't even understand what you're talking about.
Replies: >>106125534 >>106125864
Anonymous
8/3/2025, 1:03:50 PM No.106125532
>>106125466
Yeah, well that's 9obviously retarded to be using exceptions for control flow and is actually quite equivalent to if err != nil
Anonymous
8/3/2025, 1:04:37 PM No.106125534
>>106125510
Off topic, but I think that ruby syntax is trash and RoR is slow. so I don't know why companies still use it
Anonymous
8/3/2025, 1:08:08 PM No.106125551
I just write code so I don't get errors.
Anonymous
8/3/2025, 1:11:37 PM No.106125569
error handlign is fucking retarded

the only errors worth anything are crash logs with stack traces

if its making errors i dont want it running in the first place and it SHOULD crash

in fact it should fucking segfault, or worse
Replies: >>106125617 >>106125864
Anonymous
8/3/2025, 1:22:49 PM No.106125617
>>106125569
segfault is unreliable if you dont dereference NULL
and even if you do, its UB, and thus is not portable
you want a controlled exit

>>106124169 (OP)
???
check_error(routine(args))

or just hide your error handling within your function/method
Anonymous
8/3/2025, 2:14:08 PM No.106125864
>>106125510
Actual projects that may use one or more frameworks like thos, like geoserver and jenkins

>>106125569
even more retarded
pray to god you'll never work with anything that is distributed or interfacing with hardware
Anonymous
8/3/2025, 2:30:30 PM No.106125948
>>106124169 (OP)

>when I have no idea what kind of error's gonna happen

i other words you have no idea what the program does and you have no idea how to program
Anonymous
8/3/2025, 2:36:42 PM No.106125987
>>106125414
>instability of the average python/java/ruby/c# project even after decades
Retards hop on /g/ and just say stuff.
Anonymous
8/3/2025, 2:39:11 PM No.106126004
>>106124169 (OP)
there is literally no issue with err != nil, it is very readable and if typing is your problem then use snippets or go to another field

you also didn't provide any argument for the biggest problem with exceptions which is that the flow of your program becomes unpredictable
Anonymous
8/3/2025, 2:50:28 PM No.106126071
>>106124169 (OP)
webdev detected, opinion discarded
nowhere else you can just throw an error 500 and say to the user "sorry, reload the page"
Replies: >>106126187 >>106126221
Anonymous
8/3/2025, 3:01:33 PM No.106126166
>>106124169 (OP)
Exceptions are just excuse for lazy programmers or half-assed programming languages that make it intolerable (or straight impossible) to handle unhappy code-paths properly.
Replies: >>106126261
Anonymous
8/3/2025, 3:06:05 PM No.106126187
>>106126071
Polluting your code with error/exception handling so that it takes up to 2/3 of your function is severe autism, much like an itch for manual memory management. GC is fine for 90% of use cases and you literally don't need more. Just because you're dealing with hardware or writing an a real-time system doesn't mean everyone else is. But retards be retards, because they would go and write text editor in fucking javascript and then the same group of retards would go and write another text editor in Rust.
Anonymous
8/3/2025, 3:10:43 PM No.106126221
>>106126071
Also, errors and exceptions should be rare by definition. In webdev specifically it is perfectly fine to show error 500 and then just report the actual error with the traceback through some error tracking service. How else do you propose to handle it? I don't quite understand toue point. It is amazing to me that Go being a defacto hipster webshitter language decided to complicate everyone's lives with the err != nil retardation.
Anonymous
8/3/2025, 3:16:50 PM No.106126261
>>106126166
Wrong. I can literally return nil/null in ruby, js or whatever else duck typed language is used on the web, because functions can just return whatever. In fact I do and it is literally the same as go's retarded err != nil pattern, bur without the need for multiple return values. Example in Ruby:

x = henlo()
puts "henlo() didn't werk as expected" if x.nil?


Explain to me how this is isn't exactly like Go.
Replies: >>106126337
Anonymous
8/3/2025, 3:29:47 PM No.106126337
>>106126261
I'm not claiming Go is good.
I'm claiming error code-paths are just as valid as the happy ones and should be handled similarly.

Better example of proper error handling is Rust which is often lauded for its approach.
But even with Rust - with its common use of panics and then later troubled efforts to integrate Rust into Linux kernel shown us that nothing is truly exceptional - even errors like "out of memory" are not so exceptional and sometimes need to be handled properly just like regular code paths.
Replies: >>106126383
Anonymous
8/3/2025, 3:30:39 PM No.106126342
>>106124169 (OP)
Have you never heard of checked exceptions
Anonymous
8/3/2025, 3:36:21 PM No.106126383
>>106126337
I actually like Rust approach, it's elegant. And I have to admit there are domains, such as system programming, embedded or some critical systems where errors need to be handled every step of the way explicitly. However, if you start doing the same in webdev or even in regular apps, you'll never get anything done. Errors in regular applications are supposed to be a very special and rare case and if they happen, sure, it's not nice, but we can just notify the user that something went wrong and notify the developer about exactly what went wrong and either shutdown the app or keep on going.
Anonymous
8/3/2025, 3:38:38 PM No.106126395
true, but i think we shouldn't use word "error" at all. we should onlyonly think in terms exceptions and statuses.
"error handling" is just a design pattern of handling operation statuses, and not very good one, because tries to merge two responsibilites (exceptions and statuses) into one "error value" object.
Replies: >>106126429 >>106126440 >>106126943
Anonymous
8/3/2025, 3:41:21 PM No.106126417
Checked and unchecked exceptions, Optional<T> and Expected<T, E>. That is all you need, nothing more and nothing less.
Anonymous
8/3/2025, 3:43:10 PM No.106126429
>>106126395
100% agree, errors are not actually errors. Exceptions or panics are.
Anonymous
8/3/2025, 3:44:01 PM No.106126436
>>106124169 (OP)
This is literally the only thing you fags have to say about Go, not that you can't have parametrized methods or anything that might actually matter.
Anonymous
8/3/2025, 3:44:45 PM No.106126440
>>106126395
if you need to propagate the result, that's exception. if you don't, that's status.
Replies: >>106126774
Anonymous
8/3/2025, 4:22:55 PM No.106126774
>>106126440
exception is an open set of results. status is a closed set of results.
Anonymous
8/3/2025, 4:39:25 PM No.106126943
>>106126395
>i think we shouldn't use word "error" at all. we should onlyonly think in terms exceptions and statuses.
based, exceptions are control flow primitives