Exceptions are shit

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

>>39
Not even relevant.

>>38-40
Compile-time exceptions means that the compiler enforces catching the exception. It's not about exceptions being thrown during compilation.
Java is the only mainstream language I'm aware of that has both compile-time and run-time exceptions, and it calls them checked and unchecked exceptions. It might be the only thing Java does right.

>>42
I'm the real >>1, why are you posing as me? I have a public image to uphold here!

>>43
Form autofill, I apologize. orz

>>44
Apology accepted.

HAX MY ANUS

>>42
Marking all functions with throws is better than no markings at all, but it still makes error handling sloppy and you get all the same problems as usual with exceptions. Unless you wrap each line in your function with a try catch block, you don't know where the exception was thrown from, which can be very important information for the clean up. You can guess by the type of the exception thrown, but exception types are subject to change. And you never would wrap each line with a try catch block because it would be so verbose. It motivates you to deal with errors in a sloppy and unreliable way. Error codes make you ingrain error handling into the natural behavior of the function. Error handling and functionality mix. This is the perspective you should have if you want to keep correct behavior in all cases.

Though Java has finally at least.

>>42

Compile-time exceptions means that the compiler enforces catching the exception.
It's not about exceptions being thrown during compilation.

So there are no throws, what the compiler catches? Fish? Gnomes? Cats?

>>47

And you never would wrap each line with a try catch block because it would be so verbose. It motivates you to deal with errors in a sloppy and unreliable way. Error codes make you ingrain error handling into the natural behavior of the function.

Please explain how wrapping every function call that could throw an exception in a try/catch block is worse and more likely to induce sloppiness than wrapping every function call that could return an error code in a switch block (or worse, if/elif/.../else).

>>49
try {
fun1();
}
catch(Fun1Exception e) {
eek1();
}

ret = fun1();
if(ret)
eek();

>>50
Yes, congratulations, that's what it could look like. What's your argument, though?

>>51
My point is

try {
fun1();
}
catch(Fun1Exception e) {
eek1();
}
try {
fun2();
}
catch(Fun2Exception e) {
eek2();
}
try {
fun3();
}
catch(Fun3Exception e) {
eek3();
}

>>52
And? Shit can be as verbose as anything, people are still going to catch them if they want their code to compile at all. That's the whole point.
Meanwhile, your error code example is only one line shorter (if you indent/brace it the way normal people do), and there's no way to enforce looking at those.

catch(exception){
ignore exception
}

>>1
Is this really the goto argument?

>>53

People would much rather write:

try {
fun1();
fun2();
fun3();
}
catch(Fun1Exception e) {
eek1();
}
catch(Fun2Exception e) {
eek2();
}
catch(Fun3Exception e) {
eek3();
}

Which works as long as each function in each line of the try block returns a unique exception. The problem is they don't in general. If you write all your code like >>52, then the arguments don't apply, but >>52 is objectively unreadable. Note this code will still _compile. Even so, the information you have in each catch block is imprecise.

>>56
I would rather write

int errorcode = 0;
fun1(&errorcode);
fun2(&errorcode);
fun3(&errorcode);
return errorcode;

>>3
The right answer to everything is Scheme's [b][u][o][i]REIFIED[i][/o][/u][/b] continuation.

>>57

umeana

int errorcode = 0;
fun1(&errorcode); if(errorcode) return errorcode;
fun2(&errorcode); if(errorcode) return errorcode;
fun3(&errorcode); if(errorcode) return errorcode;
return errorcode;

?

>>56,57,59
U MENA

do
{ fun1
; fun2
; fun3
} :: EitherT ErrorCode m a

>>59
No. Functions fun2 and fun3 can examine the current value of the errorcode and act accordingly. For example, if there was an error in fun2, then fun3 will see it and perform cleanup, also changing the errorcode to an informative value ("fun1 did alright, but then there was an error in fun2 so fun3 had no choice but to clean up and bail").

Try to do that with exceptions.

>>60
This is primitive short-circuiting. If fun1 fails, then fun2 and fun3 don't even get a chance to do anything, i.e. no clean-up or trying alternative approaches. You seriously think that your monad crap can impress anybody these days?

int fun(struct error* err)
{
return fun1(err)
&& fun2(err)
&& fun3(err);
}

Check 'em!

NO EXCEPTIONS

Check my dubs.

>>64

Nice.

>>63
Yes. A bit like how free works with NULL for argument.

>>63
thats shit like terry davis