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

Programming Paradigms for Dummies: What Every Programmer Should Know (2009) [pdf]

info.ucl.ac.be

Post reply on HN
Print view View original

11–20 of 167 posts

Re: Programming Paradigms for Dummies: What Every Programmer Should Know (2009) [pdf]

#11

Post by jstimpfle »

beaconstudios wrote: post #9
jstimpfle wrote: post #8

Earlier quoted context omitted.

I agree and I think the conclusion is that it's up to the caller to decide what is exceptional. But unfortunately it's the callee who decides how the result is returned. And it's not only the caller, but also the caller of the caller, and so on, who needs to be prepared for exceptions. This all has severe ramifications on the code structure. > There's no need to be dismissive. I refer to simple as simple to use, not…

agreed, there are better ways to handle such circumstances (such as an Either/Validation monad). But I still think exceptions are better than error codes. If you don't handle an error code, you can proceed through your application in an invalid state. If you don't handle an exception, the application crashes out. I think the latter is preferable in most circumstances.

Yes, and this is the reason why I'm happy with exceptions for short scripts, e.g. Python. It's a different story for larger projects where I make all the primitives by myself. There I start by explicitly aborting on cases that are not handled yet (no exceptions needed to do that), and then I gradually change the structure of the code to handle more and more "exceptional" cases.

Re: Programming Paradigms for Dummies: What Every Programmer Should Know (2009) [pdf]

#12

Post by tiniuclx »

jstimpfle wrote: post #3
tiniuclx wrote: post #2

An interesting point raised by this paper is that when a program requires pervasive modifications (e.g. checking the error code returned by C functions), adding a new concept to the language (e.g. C++ exceptions) can systematically make these changes unnecessary, therefore simplifying the program. Perhaps this is how programming language designers ought to vet language ideas: do the proposed changes make certain patt…

> exceptions > simplifying Erm, no. Some consequences: non-obvious control flow, RAII, constructors, move semantics, exception safety, efficiency, stack unwinding... A better way to deal with the "problem" of unchecked error codes is to have the compiler check that something happens to the result value. This is what Chandler Carruth suggests. An even better (but orthogonal) way is to structure the code so it does onl…

You do have a point, adding exceptions to C++ does impact the language in many ways. They must be used responsibly: being able to jump to a completely different point of the program at any time is dangerous.

However, exceptions do simplify some situations, such as when an unrecoverable error happens at the bottom of a deep call stack. Exceptions make it simple to inform the user/system that an error has occurred without adding error checks to every function in the call stack. I believe this use-case justifies the feature, especially if you can tolerate the performance loss which might not even be that bad [0].

Having the compiler check error codes is one of the reasons I enjoy Haskell so much: the type system makes you handle failure (amongst other things).

[0] http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf - Section 5.4.1.2 - the table approach to exception handling has no run-time cost during normal (non-exceptional) program flow.

Re: Programming Paradigms for Dummies: What Every Programmer Should Know (2009) [pdf]

#13

Post by randcraw »

Relevant references...

A 2004 textbook by the OP:

Concepts, Techniques, and Models of Computer Programming

https://www.amazon.com/Concepts-Techniques-Models-Computer-P...

And his 6 week edX course:

Paradigms of Computer Programming – Fundamentals

https://www.edx.org/course/paradigms-of-computer-programming...

Re: Programming Paradigms for Dummies: What Every Programmer Should Know (2009) [pdf]

#14

Post by jstimpfle »

tiniuclx wrote: post #12
jstimpfle wrote: post #3

Earlier quoted context omitted.

> exceptions > simplifying Erm, no. Some consequences: non-obvious control flow, RAII, constructors, move semantics, exception safety, efficiency, stack unwinding... A better way to deal with the "problem" of unchecked error codes is to have the compiler check that something happens to the result value. This is what Chandler Carruth suggests. An even better (but orthogonal) way is to structure the code so it does onl…

You do have a point, adding exceptions to C++ does impact the language in many ways. They must be used responsibly: being able to jump to a completely different point of the program at any time is dangerous. However, exceptions do simplify some situations, such as when an unrecoverable error happens at the bottom of a deep call stack. Exceptions make it simple to inform the user/system that an error has occurred with…

The efficiency problem need not be the exception handling in itself (I can't say a lot about that. There are various claims and it probably depends on the tradeoffs of the language implementation).

The actual problem is the ramifications on the code structure. A deep call stack with a lot of implicit context is a problem in itself. Exceptions imply a temporal coupling from error occurrence to error handling. This is a subtle but severe problem. It might start out as a noticeable maintainability problem but it's likely to quickly become a performance problem as well...

Re: Programming Paradigms for Dummies: What Every Programmer Should Know (2009) [pdf]

#15

Post by beaconstudios »

jstimpfle wrote: post #11
beaconstudios wrote: post #9

Earlier quoted context omitted.

agreed, there are better ways to handle such circumstances (such as an Either/Validation monad). But I still think exceptions are better than error codes. If you don't handle an error code, you can proceed through your application in an invalid state. If you don't handle an exception, the application crashes out. I think the latter is preferable in most circumstances.

Yes, and this is the reason why I'm happy with exceptions for short scripts, e.g. Python. It's a different story for larger projects where I make all the primitives by myself. There I start by explicitly aborting on cases that are not handled yet (no exceptions needed to do that), and then I gradually change the structure of the code to handle more and more "exceptional" cases.

I suspect you're the exceptional case though (ha ha) because error codes don't cater to inexperienced developers as well as exceptions do. They are much more liable to cause your application to fail silently unless you explicitly prevent it, as you do. Good tools are all about enabling average or inexperienced developers to not fall into those pitfalls so from that perspective, exceptions are better. Usually those tools aren't very nuanced so they can get in the way of experienced or skilled developers and you end up battling the framework instead of getting productive work done. That sucks, but it's a trade-off most companies (consciously or unconsciously) accept.

Re: Programming Paradigms for Dummies: What Every Programmer Should Know (2009) [pdf]

#16

Post by AnimalMuppet »

tiniuclx wrote: post #2

An interesting point raised by this paper is that when a program requires pervasive modifications (e.g. checking the error code returned by C functions), adding a new concept to the language (e.g. C++ exceptions) can systematically make these changes unnecessary, therefore simplifying the program. Perhaps this is how programming language designers ought to vet language ideas: do the proposed changes make certain patt…

I think it's also how you should pick languages for a project. What is the worst yak-shaving aspect of the code you're going to have to write for this particular project? What language will go the furthest toward making that yak shaving go away? Pick that language.

Re: Programming Paradigms for Dummies: What Every Programmer Should Know (2009) [pdf]

#17

Post by gwright »

jstimpfle wrote: post #5
beaconstudios wrote: post #4

Earlier quoted context omitted.

compared to error codes, exceptions are simpler IMO. Many issues with exceptions come from using them in non-exceptional circumstances, i.e. for control flow.

Look up the definition of "simple". How exactly do you distinguish "exceptional" from "non-exceptional"?

The best description of exceptions that I've seen is Bertrand Meyer's exposition of them in _Object Oriented Software Construction_.

His definition depends on the notion of Design by Contract. An exception is an event that causes a function/method to fail because it is unable to satisfy its contract. The caller is then responsible for cleaning things up (so it can satisfy its contract) or it also triggers an exception resulting it its failure.

In the context of Design by Contract, the list of things that can cause an exception include:

  * hardware/OS errors
  * calling a method on a null reference
  * calling a method that itself fails
  * discovering a pre-condition isn't true
  * discovering that a post-condition isn't true
  * discovering that a class-invariant isn't true
  * loop invariant failure or lack of progress
  * assertion failures
  * explicit triggering of an exception
I highly recommend Object Oriented Software Construction.

Re: Programming Paradigms for Dummies: What Every Programmer Should Know (2009) [pdf]

#18

Post by jstimpfle »

gwright wrote: post #17
jstimpfle wrote: post #5

Earlier quoted context omitted.

Look up the definition of "simple". How exactly do you distinguish "exceptional" from "non-exceptional"?

The best description of exceptions that I've seen is Bertrand Meyer's exposition of them in _Object Oriented Software Construction_. His definition depends on the notion of Design by Contract. An exception is an event that causes a function/method to fail because it is unable to satisfy its contract. The caller is then responsible for cleaning things up (so it can satisfy its contract) or it also triggers an exceptio…

I think this is a hair-splitting distinction and it does not work reliably. Sorry. Things that truly "cannot" happen => you do not know how to recover => you terminate the program. That's it.

Re: Programming Paradigms for Dummies: What Every Programmer Should Know (2009) [pdf]

#19

Post by gwright »

jstimpfle wrote: post #18
gwright wrote: post #17

Earlier quoted context omitted.

The best description of exceptions that I've seen is Bertrand Meyer's exposition of them in _Object Oriented Software Construction_. His definition depends on the notion of Design by Contract. An exception is an event that causes a function/method to fail because it is unable to satisfy its contract. The caller is then responsible for cleaning things up (so it can satisfy its contract) or it also triggers an exceptio…

I think this is a hair-splitting distinction and it does not work reliably. Sorry. Things that truly "cannot" happen => you do not know how to recover => you terminate the program. That's it.

That is why the definition is recursive. If every failure triggers a new exception all the way up the call stack, then your program fails.

Re: Programming Paradigms for Dummies: What Every Programmer Should Know (2009) [pdf]

#20

Post by jstimpfle »

gwright wrote: post #19
jstimpfle wrote: post #18

Earlier quoted context omitted.

I think this is a hair-splitting distinction and it does not work reliably. Sorry. Things that truly "cannot" happen => you do not know how to recover => you terminate the program. That's it.

That is why the definition is recursive. If every failure triggers a new exception all the way up the call stack, then your program fails.

Yeah, so what was the point to begin with?
Post reply on HN