Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Exceptions are shit

Name: Anonymous 2015-02-21 10:49

http://www.lighterra.com/papers/exceptionsharmful/

Name: Anonymous 2015-02-21 11:35

Error codes are the Right thing, but programmers are too lazy to implement proper error handling and exceptions won as worse-is-better. Comefrom comparison is neatly illustrating how non-intuitive exception hidden state is.

Name: Anonymous 2015-02-21 11:42

The right answer to everything is CL's condition and restarts system.

Name: Anonymous 2015-02-21 18:42

http://www.lighterra.com/papers/modernmicroprocessors/

What About x86?

So where does x86 fit into all this, and how have Intel and AMD been able to remain competitive through all of these developments in spite of an architecture that's now more than 30 years old?

Ahahaha he's definitely /prog/ material.

Name: Anonymous 2015-02-25 20:48

bump for quality

Name: Anonymous 2015-02-26 6:29

>>2
It's funny to take the intersection of the set of people that advocate for exceptions with the set if people who condemn more explicit nonlocal control transfers (i.e., longjmp). This cognitive dissonance is so widespread it passes for conventional wisdom.

Name: Anonymous 2015-02-26 11:00

The mismatch with parallel programming is a reasonable enough argument, but everything else is wordy bullshit. At best he makes the case that exceptions as commonly implemented have rough edges (though he mostly doesn't even manage that); at no point does he make any sort of case that error codes are any better.
The unintentional loud failure through exceptions is the wrong thing to do in many conceivable cases, absolutely. Replacing it with the unintentional quiet failure that just keeps churning that typifies code using error codes (and was the whole reason people moved away from them to begin with) is worse in very nearly every case.

Name: Anonymous 2015-02-26 14:20

>>7
you don't need to stuff error codes inside returned vars
Its from the time stdlib was developed.
now you can put error codes anywhere, and send them to func
int func3(int param, int* error_code_returned_here){
if(param==0) {*error_code_returned_here=1;return 1;}
return param/3;}

Name: Anonymous 2015-02-26 20:02

>>8
I don't know which part of >>7 you think that addresses.

Name: Anonymous 2015-02-27 4:43

>>9
>typifies code using error codes

Name: Anonymous 2015-02-27 9:26

rolling for dubs

Name: Anonymous 2015-02-27 9:40

>>11
DubsException::throw new DubsException("Invalid dubs handler, unchecked dubs at line 11: stack corrupted")

Name: Anonymous 2015-03-01 5:01

>>10
I seriously don't understand why you think >>8 addresses that.

Name: Anonymous 2015-03-01 5:44

>>13
1.error codes forces the return type to contain an error code(typically 0). so using 0(or any other number which is defined as error e.g. -1) as return value is reserved.
2.Exceptions don't restrict return type
3.if error code is returned to separate variable #1 does not apply

Name: Anonymous 2015-03-01 6:15

Global somethingWentWrong as boolean
Global sWWfunctionId as integer
Global sWWtestId as integer

Name: Anonymous 2015-03-01 6:21

>>14
Okay, but none of that is what >>7 is complaining about.

Name: Anonymous 2015-03-01 7:43

>>15
Globals are even more shit than exceptions.

>>14
Just use Either ErrorReport Value

Name: Anonymous 2015-03-01 8:30

>>7
You have troubles with reading, obviously. It's actually the exceptions that are prone to silently corrupt the data, not the error codes which are explicit.

Name: Anonymous 2015-03-01 21:10

>>18
Sure, if you ignore how exceptions and error codes are actually used in practice, that's true.
Fact is, people often ignore error codes because they can and usually catch and handle exceptions because they have to.

This isn't the goto argument, where both theoretical purity and actual practice said it needed to go; actual practice bears out exceptions are a good thing (compared to the available alternatives), and only theoretical purity is in conflict. That matters for research languages like Haskell, but it's completely irrelevant for languages that people actually use.

Name: Anonymous 2015-03-02 0:29

>>18
If you could enforce that error codes were addressed by the caller it would be safer than exceptions.

Name: Anonymous 2015-03-02 0:37

>>20 was to >>19

Name: Anonymous 2015-03-02 0:54

>>21
No one cares.

Name: Anonymous 2015-03-02 1:13

>>22
Cut down the grouch, dubs-kun.

Name: Anonymous 2015-03-02 1:48

>>20
If you could enforce that error codes were addressed by the caller and also carried around some state to indicate details about the error you'll have reinvented compile-time exceptions.

Name: Anonymous 2015-03-02 1:57

>>24
Except the semantics are obvious by looking at the code. You don't have unexpected non local jumps that forget to free resources and otherwise recover in subtle incorrect ways.

Name: Anonymous 2015-03-02 2:29

>>25
Except for the part where there's absolutely nothing stopping that from happening with error codes.

Name: Anonymous 2015-03-02 5:14

>>26
If you could enforce that error codes were addressed by the caller
Ok I'm done. HAND

Name: Anonymous 2015-03-02 9:10

Who is this exception wanker?

Name: Anonymous 2015-03-02 13:05

>>27
Enforcing handling of error codes does exactly the same thing as enforcing compile-time exceptions, genius. There's nothing about error codes that magically makes people clean up after themselves.
You can't seriously be this dense.

Name: Anonymous 2015-03-02 17:42

>>29
Um, yes there is. It's the return codes. They are, like, returned. If that's too hard for you to understand (you're not the brightest lantern in the shed, I know, but please, just this once, bear with me), then I'll spell it out for you:

error
codes

What does that spell? "error codes"! We're already half-way there!

are
returned

"are returned"! Bet you saw that coming, didn't you? Now put it all together and enjoy a moment of your own brilliance:

"error codes are returned"!

They're returned by the function! In a most explicit way! That's what makes error codes be more obvious that the functions need clean-up! This is a lot different from exceptions which in no way indicate that there is ever a need to do clean-up! Now wipe your drool, >>29, it's time to go eat some nuggets! Boy, do you love some chicken nuggets!

Name: Anonymous 2015-03-02 18:07

NO EXCEPTIONS

Name: Anonymous 2015-03-03 9:23

>>31::FatalExceptionException("No exception handler exception: core dumped")

Name: Anonymous 2015-03-03 10:09

Dubs =)

Name: Anonymous 2015-03-03 10:21

>>33
Feels dubs 3).jpg

Name: Anonymous 2015-03-03 11:42

>>30
Have you ever even seen a language with compile-time exceptions?

Name: Anonymous 2015-03-03 12:04

>>35 Actually they exist
#if baz==foo
#error Exception:baz is exactly foo
#endif

Name: Anonymous 2015-03-03 14:08

>>36
Of course they exist, but it seems like >>30 has never actually seen one. Either that or he was dropped as a child.

Name: Anonymous 2015-03-03 17:59

>>35
Gods, why would anyone need compile-time exceptions? Exceptions are for recovery from runtime errors.

Name: Anonymous 2015-03-03 18:03

>>38
http://en.wikipedia.org/wiki/Compile_time_function_execution

Name: Anonymous 2015-03-03 18:10

D has Exceptions in CTFE(compile-time) since 2009
http://www.digitalmars.com/d/archives/digitalmars/D/bugs/Issue_3050_New_Allow_exception_in_CTFE_patch_17697.html
Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List
All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode + RSS -