Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Errors and Exceptions

giantfublog.wordpress.com

Post reply on HN
Print view View original

51–55 of 55 posts

Re: Errors and Exceptions

#51

Post by w0000t »

jcranmer wrote: post #48
w0000t wrote: post #14

Earlier quoted context omitted.

The problem is it needs to be applied to every function that returns a value. And I'm pretty sure you can't apply it to C library functions. Gcc seriously needs a global flag for this.

You might be surprised at the warnings you'd get. Did you know, for example, that printf returns a value? It's also a return value that rarely, if ever, tends to be useful.

Yes, I did. But so far I haven't been regularly checking printf return value. :-( I wonder if checking the result of every printf or asserting it, depending on the circumstances, would reduce the amount of time spent on writing+debugging the code on the long run.

Re: Errors and Exceptions

#52

Post by Animats »

barrkel wrote: post #7
jblow wrote: post #5

Earlier quoted context omitted.

I also prefer option 3 over option 4. It bothers me that the article recommends exceptions without seeming to understand their drawbacks (the major one: as soon as you use exceptions you suddenly need to apply nonlocal reasoning everywhere in order to understand what your program will do at any point. They turn your program from a simple local thing into a complex nonlocal thing, which is not a good idea if you want…

In this age when we are realizing strong typing is a good idea, that hidden state is a bad idea, and that in general you should be very specific about what is going on Java tried to be typesafe about errors, about not obscuring the state, and it was a dreadful idea. The way code fails is a function of its implementation; communicating high quality error information is fundamentally an abstraction violation, but a str…

Exceptions are hard to get right in language design. They're easier in a garbage-collected language like Python, because there's not so much need to release stuff. Most of the bad reputation of exceptions comes from C++, where the combination of exceptions, RAII, and having to release memory results in problems.

Without exceptions, programs seem to develop too many "goto" statements. Go suffers in this way. Error handling in Rust seems to excessively complex, and hiding the complexity inside macros that do return statements is an ugly solution to the problem.

Re: Errors and Exceptions

#53

Post by lukasLansky »

jblow wrote: post #22
lukasLansky wrote: post #18

Earlier quoted context omitted.

Strong type system with a good support of checked exceptions would tell you what kind of exceptions can arise from every function call. If you don't check them in your function code, they would add to the list of exceptions that your function can throw. It would basically turn every function you write with return type T into Either with syntax sugar that would transfer exceptions between calls so you don't have to sp…

With this scheme you would end up with pretty bad problems regarding function pointers and lambdas. Because the type is deeply implicit, you would have two function pointers that look compatible but are totally incompatible. Then when you want to assign them to a variable -- how do you know a priori what type to declare the variable?

Good question. :-) I guess there definitely would be cases where the programmer would be restricted in what they want to do -- this is a nature of type systems. For example, I guess following code would not compile:

var f = (n) => n / 5; f = (n) => 5 / n;

What I hope for is that usual patterns would survive in a convenient manner. For example, calling function with function argument that is evaluated inside this function is something that could be handled by language without too many problems.

Re: Errors and Exceptions

#55

Post by Quiark »

simula67 wrote: post #17

This article caused me to lose my faith in exceptions : http://ptgmedia.pearsoncmg.com/images/020163371x/supplements...

That article is extremely outdated and by today standards quite ill-informed. Many of its arguments could be equally made for error codes.

Try some of these instead:

    http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Andrei-Alexandrescu-Systematic-Error-Handling-in-C
    www.boost.org/community/exception_safety.html
    https://github.com/Quiark/CppExceptDetails
    http://www.boost.org/community/error_handling.html
Post reply on HN