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?
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. 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.finally at least. Compile-time exceptions means that the compiler enforces catching the exception.So there are no throws, what the compiler catches? Fish? Gnomes? Cats?
It's not about exceptions being thrown during compilation.
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).
try {
fun1();
}
catch(Fun1Exception e) {
eek1();
}
try {
fun2();
}
catch(Fun2Exception e) {
eek2();
}
try {
fun3();
}
catch(Fun3Exception e) {
eek3();
} try {
fun1();
fun2();
fun3();
}
catch(Fun1Exception e) {
eek1();
}
catch(Fun2Exception e) {
eek2();
}
catch(Fun3Exception e) {
eek3();
}int errorcode = 0;
fun1(&errorcode);
fun2(&errorcode);
fun3(&errorcode);
return errorcode; int errorcode = 0;
fun1(&errorcode); if(errorcode) return errorcode;
fun2(&errorcode); if(errorcode) return errorcode;
fun3(&errorcode); if(errorcode) return errorcode;
return errorcode;int fun(struct error* err)
{
return fun1(err)
&& fun2(err)
&& fun3(err);
}