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

21–30 of 167 posts

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

#21

Post by gnoack »

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've written an article on error handling some point and ended up with: "An error is when the program is operating outside the intended path of execution."

What counts as intended is a question of definition, but in concrete examples of local reasoning within a function this question is usually easier to answer. Thinking about it in terms of (explicit or implicit) contracts, like Bertrand Meyer, sounds like a smart idea.

https://blog.gnoack.org/post/error_handling/

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

#22

Post by dahart »

The footnote in section 2.1 caught my eye:

> Similar reasoning explains why Baskin-Robbins has exactly 31 flavors of ice cream. We postulate that they have only 5 flavors, which gives 25 − 1 = 31 combinations with at least one flavor. The 32nd combination is the empty flavor. The taste of the empty flavor is an open research question.

I honestly can’t tell if this is a good joke or serious & bad logic. The 31 flavors are obviously not a mix of 5 base flavors. If that were the case, each base flavor would be in 16 of the mixed flavors, and you wouldn’t have any unique flavors at all, like mint or cookie dough. It’s just a coincidence that the longest months in the year are 2^5-1 days.

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

#23

Post by gwright »

jstimpfle wrote: post #20
gwright wrote: post #19

Earlier quoted context omitted.

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?

Do you understand Design By Contract? That is the theory that provides the distinction between a function/method finishing with success or with failure. The notion of contract is what distinguishes an exception from a glorified GOTO.

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

#24

Post by de_Selby »

dahart wrote: post #22

The footnote in section 2.1 caught my eye: > Similar reasoning explains why Baskin-Robbins has exactly 31 flavors of ice cream. We postulate that they have only 5 flavors, which gives 25 − 1 = 31 combinations with at least one flavor. The 32nd combination is the empty flavor. The taste of the empty flavor is an open research question. I honestly can’t tell if this is a good joke or serious & bad logic. The 31 flavors…

>I honestly can’t tell if this is a good joke...

I'll help out: It's a joke.

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

#25

Post by dahart »

de_Selby wrote: post #24
dahart wrote: post #22

The footnote in section 2.1 caught my eye: > Similar reasoning explains why Baskin-Robbins has exactly 31 flavors of ice cream. We postulate that they have only 5 flavors, which gives 25 − 1 = 31 combinations with at least one flavor. The 32nd combination is the empty flavor. The taste of the empty flavor is an open research question. I honestly can’t tell if this is a good joke or serious & bad logic. The 31 flavors…

>I honestly can’t tell if this is a good joke... I'll help out: It's a joke.

For sure? I skimmed the whole thing and couldn’t immediately find any other jokes. Seems an odd choice to throw in one random deadpan comment about the coincidence of 31 being near a power of two.

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

#26

Post by uryga »

jstimpfle wrote: post #14
tiniuclx wrote: post #12

Earlier quoted context omitted.

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…

> Exceptions imply a temporal coupling from error occurrence to error handling.

Could you expand on this? I understood your statement as "Exceptions sort-of force you to handle an error the moment it occurs", but I'm having trouble seeing why this would be specific to exceptions and not the case with other error handling solutions.

(I don't mean to sound like a big exception-defender – I prefer ML/Rust-style Result types)

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

#27

Post by jstimpfle »

gnoack wrote: post #21
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've written an article on error handling some point and ended up with: "An error is when the program is operating outside the intended path of execution." What counts as intended is a question of definition, but in concrete examples of local reasoning within a function this question is usually easier to answer. Thinking about it in terms of (explicit or implicit) contracts, like Bertrand Meyer, sounds like a smart i…

> Warning: Textual logging is not an error handling strategy. Logs are not meant for machine consumption so it’s hard to have automated monitoring based on them.

I'd beg to disagree.

As for the general statement of your post, I like how you're talking about stakeholders and (specification) bounds but I don't think it's an actionable viewpoint. The idea of "Bubbling up errors" inside a program is caught in the software reuse mindset but it's not possible to take action on encountering a true error (here "true" means "outside specifiation"). That's because the state of your whole program is undefined after the encounter. Which means that the best you can do is to call abort() and hope that the program will end with some info for debugging.

(Unless we are talking about a VM or sandboxed code, in which case again you could just call some equivalent of abort() from the code inside and "catch" that in the host code and restart the VM or something).

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

#29

Post by gbear605 »

uryga wrote: post #26
jstimpfle wrote: post #14

Earlier quoted context omitted.

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…

> Exceptions imply a temporal coupling from error occurrence to error handling. Could you expand on this? I understood your statement as "Exceptions sort-of force you to handle an error the moment it occurs", but I'm having trouble seeing why this would be specific to exceptions and not the case with other error handling solutions. (I don't mean to sound like a big exception-defender – I prefer ML/Rust-style Result t…

A rather odd example with Result type systems: Say you have a function that returns the results of three other functions together in a tuple and the first one errors. The other two can still run and their result can be returned in the tuple along with an Error for the first function.

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

#30

Post by mturmon »

dahart wrote: post #25
de_Selby wrote: post #24

Earlier quoted context omitted.

>I honestly can’t tell if this is a good joke... I'll help out: It's a joke.

For sure? I skimmed the whole thing and couldn’t immediately find any other jokes. Seems an odd choice to throw in one random deadpan comment about the coincidence of 31 being near a power of two.

Definitely a joke. The "open research question" kicker makes that clear. There's a similar jokey footnote on page 33.
Post reply on HN