this post was submitted on 04 Mar 2024
333 points (99.7% liked)
196
18044 readers
1122 users here now
Be sure to follow the rule before you head out.
Rule: You must post before you leave.
Other rules
Behavior rules:
- No bigotry (transphobia, racism, etc…)
- No genocide denial
- No support for authoritarian behaviour (incl. Tankies)
- No namecalling
- Accounts from lemmygrad.ml, threads.net, or hexbear.net are held to higher standards
- Other things seen as cleary bad
Posting rules:
- No AI generated content (DALL-E etc…)
- No advertisements
- No gore / violence
- Mutual aid posts are not allowed
NSFW: NSFW content is permitted but it must be tagged and have content warnings. Anything that doesn't adhere to this will be removed. Content warnings should be added like: [penis], [explicit description of sex]. Non-sexualized breasts of any gender are not considered inappropriate and therefore do not need to be blurred/tagged.
If you have any questions, feel free to contact us on our matrix channel or email.
Other 196's:
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I’m even more disturbed by the try catch that will never catch anyway. Most disturbing is the absolute heresy that is the throw within the catch. …is vibe even defined here??? I think I need to reconsider my major.
Catching and rethrowing just to log the error is a valid use of a try catch IMO
If you don't care anything about performance, absolutely
My personal take on this, at least when dealing with more complex or production code:
Performance is not an issue with exceptions if you don't use them for control flow, they should be an unusual occurrence wherever possible.
If you expect to throw and later handle an exception regularly, I'd try to include relevant info about the failure in the returned value, or even better in the returned type, and skip throwing the exception altogether.
Returning a type that contains both error info and the actual result (if there is one) and forces the caller of your function to handle any contained error info before being able to access the actual result has the same effect as a try/catch block without the major performance implications.
This is basically what rust does everywhere in order to completely remove the concept of exceptions, but it's a nice performance optimization for langues with exceptions as well.
Exceptions should interrupt your programs flow, not control it, at least in all hot execution paths. Thanks for coming to my ted talk
Performance isn't an issue if you don't care about performance, correct.