RE: [Boost-Users] Re: [BGL] Best way to abort an algorithm from w ithi n a visitor?

Mark Storer

18 Sep 2002 18 Sep '02

8:44 p.m.

Using exceptions in this way just bugs me. Religious reasons I guess. As the Esteemed Mr. Hylsop ;) mentioned earlier, exceptions are for "oops". This seems alot like the whole "do{}while(0)" with various 'break' statements sprinkled in to avoid multiple returns/nested ifs. Useful, but Just Not Right. Your code has cooties! Nobody's going to want to sit next to it during recess...

...

So there's no way to affect feedback to the algorithm's dispatcher without actually making modifications to the algorithm code.

So modify away. Seems like a "breath_first_until" sort of thing would be quite useful. Pass in some sort of predicate, and away you go. I'm sure the community at large would be grateful. --Mark Storer Software Engineer Cardiff Software #include <disclaimer> typedef std::disclaimer<Cardiff> Discard; -----Original Message----- From: Chris Russell [mailto:cdr@encapsule.com] Sent: Wednesday, September 18, 2002 1:27 PM To: boost-users@yahoogroups.com Subject: [Boost-Users] Re: [BGL] Best way to abort an algorithm from withi n a visitor?

...

Now if you've got more than a hundred or so entries left to go, exceptions really are the greener grass.

The size of the graph is not known a-priori (not at coding time anyway) but is likely to be quite large.

...

What's wrong with 'return', perhaps along-side some sort of 'done' status variable? I'm only vaguely familiar with the visitor pattern, but these would seem to be the obvious choice.

...

If efficiency is your goal, exceptions are not the answer. Just enabling exceptions at compile time makes a noticable performance hit. Actually throwing an exception can gobble up a 1000 cycles, give or take. That's

See my earlier reply. In this case I'm deriving my visitor from a base and overriding "event" handlers that receive their marching orders via const references and return void. So there's no way to affect feedback to the algorithm's dispatcher without actually making modifications to the algorithm code. "Mark Storer" wrote in message news:E840F0B7E6189547BDB91DA8BF2228AB016255F8@csmail.cardiff.com... per

...

throw. If you catch and throw again, you'll pay again.

Now if you've got more than a hundred or so entries left to go, exceptions really are the greener grass.

What's wrong with 'return', perhaps along-side some sort of 'done' status variable? I'm only vaguely familiar with the vistor pattern, but these would seem to be the obvious choice.

--Mark Storer Software Engineer Cardiff Software

#include <disclaimer> typedef std::disclaimer<Cardiff> Discard;

Info: http://www.boost.org Wiki: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl Unsubscribe: mailto:boost-users-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Show replies by date

Chris Russell

18 Sep 18 Sep

8:54 p.m.

New subject: [BGL] Best way to abort an algorithm from withi n a visitor?

I suppose you're right. Point well taken. "Mark Storer" wrote in message news:E840F0B7E6189547BDB91DA8BF2228AB016255F9@csmail.cardiff.com...

...

Using exceptions in this way just bugs me. Religious reasons I guess. As the Esteemed Mr. Hylsop ;) mentioned earlier, exceptions are for "oops". This seems alot like the whole "do{}while(0)" with various 'break' statements sprinkled in to avoid multiple returns/nested ifs. Useful, but Just Not Right.

Your code has cooties! Nobody's going to want to sit next to it during recess...

...
So there's no way to affect feedback to the algorithm's dispatcher without actually making modifications to the algorithm code.

So modify away. Seems like a "breath_first_until" sort of thing would be quite useful. Pass in some sort of predicate, and away you go. I'm sure the community at large would be grateful.

--Mark Storer Software Engineer Cardiff Software

#include <disclaimer> typedef std::disclaimer<Cardiff> Discard;

-----Original Message----- From: Chris Russell [mailto:cdr@encapsule.com] Sent: Wednesday, September 18, 2002 1:27 PM To: boost-users@yahoogroups.com Subject: [Boost-Users] Re: [BGL] Best way to abort an algorithm from withi n a visitor?

...
Now if you've got more than a hundred or so entries left to go, exceptions really are the greener grass.

The size of the graph is not known a-priori (not at coding time anyway) but is likely to be quite large.

...
What's wrong with 'return', perhaps along-side some sort of 'done' status variable? I'm only vaguely familiar with the visitor pattern, but these would seem to be the obvious choice.

See my earlier reply. In this case I'm deriving my visitor from a base and overriding "event" handlers that receive their marching orders via const references and return void. So there's no way to affect feedback to the algorithm's dispatcher without actually making modifications to the algorithm code.

...
If efficiency is your goal, exceptions are not the answer. Just enabling exceptions at compile time makes a noticable performance hit. Actually throwing an exception can gobble up a 1000 cycles, give or take. That's

"Mark Storer" wrote in message news:E840F0B7E6189547BDB91DA8BF2228AB016255F8@csmail.cardiff.com... per

...
throw. If you catch and throw again, you'll pay again.

Now if you've got more than a hundred or so entries left to go, exceptions really are the greener grass.

What's wrong with 'return', perhaps along-side some sort of 'done' status variable? I'm only vaguely familiar with the vistor pattern, but these would seem to be the obvious choice.

--Mark Storer Software Engineer Cardiff Software

#include <disclaimer> typedef std::disclaimer<Cardiff> Discard;

Info: http://www.boost.org Wiki: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl Unsubscribe: mailto:boost-users-unsubscribe@yahoogroups.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Peter Dimov

19 Sep 19 Sep

4:19 p.m.

New subject: [Boost-Users] Re: [BGL] Best way to abort an algorithm from withi n a visitor?

From: "Mark Storer"

...

Using exceptions in this way just bugs me. Religious reasons I guess. As the Esteemed Mr. Hylsop ;) mentioned earlier, exceptions are for "oops". This seems alot like the whole "do{}while(0)" with various 'break' statements sprinkled in to avoid multiple returns/nested ifs. Useful, but Just Not Right.

A common misconception. Many people try to project their own ideas/expectations on language features, rather than simply using them as tools where appropriate. There is nothing "oops"-y about exceptions. They are a control flow mechanism; one that has interesting properties, but a control flow mechanism nonetheless. If it works and leads to a better code, it's foolish to avoid it without a technical reason. A similar example is when people don't use "struct" for C++ classes because it "doesn't feel right", or when trying to choose between "typename" and "class" for template parameters. The language features simply do not carry this kind of religious/emotional payload. It's all in your mind.

Jeff Faust

4:28 p.m.

New subject: [Boost-Users] Re: [BGL] Best way to abort an algorithm from withi n a visitor?

Something is more maintainable if it is more understood. Exceptions are meant for exceptional cases. At least that's a common conception, one which I follow. Even thier name suggests their usage. Maintenance is a very good reason to stay within expectations. Staying within expectations may mean sacrificing performance. There is often a trade-off between performance and maintainability. The pros and cons should be weighed and a choice made. Jeff -----Original Message----- From: Peter Dimov [mailto:pdimov@mmltd.net] From: "Mark Storer"

...

Using exceptions in this way just bugs me. Religious reasons I guess. As the Esteemed Mr. Hylsop ;) mentioned earlier, exceptions are for "oops". This seems alot like the whole "do{}while(0)" with various 'break' statements sprinkled in to avoid multiple returns/nested ifs. Useful, but Just Not Right.

Peter Dimov

5:40 p.m.

New subject: [Boost-Users] Re: [BGL] Best way to abort an algorithm from withi n a visitor?

From: "Jeff Faust"

...

Something is more maintainable if it is more understood.

Even if it's made more complicated by littering the algorithms with completely redundant return value checks?

...

Exceptions are meant for exceptional cases. [...]

Define "exceptional cases". How exceptions work is well defined, and therefore can be understood, whereas an "exceptional case" is always assumed to be intuitively obvious.

...

Staying within expectations may mean sacrificing performance. There is often a trade-off between performance and maintainability. The pros and cons should be weighed and a choice made.

Performance? It's about code clarity, not performance.

Jeremy Siek

5:59 p.m.

New subject: [Boost-Users] Re: [BGL] Best way to abort an algorithm from withi n a visitor?

Here's what went on in my head when I thought about this issue: Performance =========== Throw +main execution path of algorithm is fast -have to leave exception handling turned on Return flag -insert if's throughout main execution path, causes slowdowns +can turn off exception handling I haven't done any experiments to compare the above, but since people shouldn't be turning off exception handling anyways, and some compilers do a decent job w.r.t. performance with exception handling, I think this is in favor of throwing. Code Clarity ============ Throw + algorithm code is uncluttered Return flag - if's in the algorithm code add clutter to sometimes already complicated algorithm. Here, the adv. is cleary for throw. So I went with throw. Cheers, Jeremy ---------------------------------------------------------------------- Jeremy Siek http://php.indiana.edu/~jsiek/ Ph.D. Student, Indiana Univ. B'ton email: jsiek@osl.iu.edu C++ Booster (http://www.boost.org) office phone: (812) 855-3608 ----------------------------------------------------------------------

Jeff Faust

6:04 p.m.

New subject: [Boost-Users] Re: [BGL] Best way to abort an algorithm from withi n a visitor?

...

From: Peter Dimov [mailto:pdimov@mmltd.net]

...
Something is more maintainable if it is more understood.

Even if it's made more complicated by littering the algorithms with completely redundant return value checks?

In this case, yes, and I'd hardly call it redundant. It sounds like a useful mechanism to be able to stop the algorithm from processing once a goal is achieved. There is no such mechanism built in. Exceptions can be used to achieve this, but it's not how exceptions are commonly used, and not how they are commonly understood.

...

...
Exceptions are meant for exceptional cases. [...]

Define "exceptional cases". How exceptions work is well defined, and therefore can be understood, whereas an "exceptional case" is always assumed to be intuitively obvious.

Something unexpected. The example give by the original poster is describing a normal execution. This is not unexpected. It's strange to think that what occurs in the catch block is not error recover/reporting, but normal and expected execution. This is not an obvious usage of exceptions.

...

...
Staying within expectations may mean sacrificing performance. There is often a trade-off between performance and maintainability. The pros and cons should be weighed and a choice made.

Performance? It's about code clarity, not performance.

I was looking at the choice between using exceptions and letting the algorithm run to completion. I was not thinking about modifying the algorithm. My oversight. Of course everything I say is by today's standards and those standards may change. But since tomorrow's standards are unknown, it's a bad argument, and an argument that could be used to support anything. Jeff Faust

Steve M. Robbins

6:38 p.m.

New subject: [Boost-Users] Re: [BGL] Best way to abort an algorithm from withi n a visitor?

On Thu, Sep 19, 2002 at 11:04:12AM -0700, Jeff Faust wrote:

...

...
...
Exceptions are meant for exceptional cases. [...]

Define "exceptional cases". How exceptions work is well defined, and therefore can be understood, whereas an "exceptional case" is always assumed to be intuitively obvious.

Something unexpected. The example give by the original poster is describing a normal execution. This is not unexpected. It's strange to think that what occurs in the catch block is not error recover/reporting, but normal and expected execution. This is not an obvious usage of exceptions.

Jeff Faust

7:28 p.m.

New subject: [Boost-Users] Re: [BGL] Best way to abort an algorithm from withi n a visitor?

...

I think you're imposing your own experience on the question.

Admittedly, I am using my own experience on the question. Without the experience, I would have had the common decency to remain quiet on the issue.

...

Reaching the "end node" is an exceptional case.

An exceptional case that happens with every run can hardly be called exceptional.

...

It is clear from the discussion that I'm not alone in viewing this as a normal use of exceptions.

Nor am I alone. I don't know what the best solution is--I'm not sufficiently familiar with the OP's problem. Maybe it's not a common need and shouldn't be part of the algorithm. Maybe making it part of the algorithm would slow it down too much to be effective. Maybe exceptions are the best way to handle this in light of everything else. What I do know, as constrained by my experience, is that exceptions are not usually used in this manner. It's different and a bit "tricky", but it produces the results you need. This type of reasoning, in my experience, is best met with suspicion, and should be approached in full awareness of the issues. That doesn't make it wrong. Jeff -----Original Message----- From: Steve M. Robbins [mailto:steven.robbins@videotron.ca] Sent: Thursday, September 19, 2002 11:39 AM To: Boost-Users@yahoogroups.com Subject: Re: [Boost-Users] Re: [BGL] Best way to abort an algorithm from withi n a visitor? On Thu, Sep 19, 2002 at 11:04:12AM -0700, Jeff Faust wrote:

...

...
...
Exceptions are meant for exceptional cases. [...]

Define "exceptional cases". How exceptions work is well defined, and therefore can be understood, whereas an "exceptional case" is always assumed to be intuitively obvious.

Something unexpected. The example give by the original poster is describing a normal execution. This is not unexpected. It's strange to think that what occurs in the catch block is not error recover/reporting, but normal and expected execution. This is not an obvious usage of exceptions.

I think you're imposing your own experience on the question. In the case at hand, using an exception seemed perfectly natural to *me*, for all the reasons that Jeremy just outlined. It is clear from the discussion that I'm not alone in viewing this as a normal use of exceptions. Think of it this way: the normal course of action for a "visitor" is to process a node. Reaching the "end node" is an exceptional case. -Steve Info: http://www.boost.org Wiki: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl Unsubscribe: mailto:boost-users-unsubscribe@yahoogroups.com Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

David Abrahams

20 Sep 20 Sep

11:26 a.m.

New subject: [BGL] Best way to abort an algorithm from withi n a visitor?

"Jeff Faust" wrote in message news:ICEELEJLOALJHNHFDNIDEEJNDFAA.jeff@opticalres.com...

...

An exceptional case that happens with every run can hardly be called exceptional.

One should be wary of ideas that ring too nicely in the ear. Just look, for example, at how easily taken people in the Physics community (a rigorous lot!) have been taken by ideas like "self-organized criticality". Exceptions are a ripe source of such misconceptions, since their name conjures up so much "meaning" The rule that "exceptions should only be used for exceptional cases" is bogus, and it always has been. One problem is that it is based on a highly subjective term, "exceptional". The other problem is that it doesn't map well onto the semantics of the actual language construct (stack unwinding). Exceptions should be used anywhere that their semantics and efficiency are appropriate to the problem. I probably shouldn't mention this, but if you insist on keeping your rule you can stretch it to fit the use-case: in a really large graph, finding the target node is highly exceptional. You may eventually get there in every case, but it may only be after examining 100,000 nodes. All of the visits which don't find the target account for the non-exceptional cases. This is the one way in which the "rule" is not completely bogus: the implementation of most EH mechanisms sacrifices the efficiency of the paths where an exception is thrown to get higher efficiency in the non-throwing code paths. Thus, it makes sense not to repeatedly throw exceptions from your inner loops. It would be better to say, "exceptions should be used (comparitively) rarely". -- ----------------------------------------------------------- David Abrahams * Boost Consulting dave@boost-consulting.com * http://www.boost-consulting.com

Jeff Faust

3:32 p.m.

New subject: [Boost-Users] [BGL] Best way to abort an algorithm from within a visitor?

Advice from three prevalent boost developers should not be dismissed, and indeed I won't. However, I will maintain my purist stance on this issue until such a need arises for me to reexamine that stance. Thanks for everybody's arguments. I'll keep them in mind. Jeff -----Original Message----- From: news [mailto:news@main.gmane.org]On Behalf Of David Abrahams Sent: Friday, September 20, 2002 4:27 AM To: boost-users@yahoogroups.com Subject: [Boost-Users] Re: Re: [BGL] Best way to abort an algorithm from withi n a visitor? "Jeff Faust" wrote in message news:ICEELEJLOALJHNHFDNIDEEJNDFAA.jeff@opticalres.com...

...

An exceptional case that happens with every run can hardly be called exceptional.

One should be wary of ideas that ring too nicely in the ear. [...]

Chris Russell

7:58 p.m.

New subject: [BGL] Best way to abort an algorithm from within a visitor?

Gee - I certainly didn't expect any controversy over this particular question ;) Thanks for the help all. I have elected to use the exceptions approach in my case as the number of vertices/edges in my graph is large and the ratio of time spent unwinding the stack upon reaching my goal condition vs. executing the algorithm to determine if there the condition is met at all approaches zero. I should note that the exception method additionally has the benefit of allowing me to throw the exact details back to the calling code in a very clear and explicit manner. Thanks again - Chris "Jeff Faust" wrote in message news:ICEELEJLOALJHNHFDNIDAEKFDFAA.jeff@opticalres.com...

...

Advice from three prevalent boost developers should not be dismissed, and indeed I won't. However, I will maintain my purist stance on this issue until such a need arises for me to reexamine that stance. Thanks for everybody's arguments. I'll keep them in mind.

Jeff

-----Original Message----- From: news [mailto:news@main.gmane.org]On Behalf Of David Abrahams Sent: Friday, September 20, 2002 4:27 AM To: boost-users@yahoogroups.com Subject: [Boost-Users] Re: Re: [BGL] Best way to abort an algorithm from withi n a visitor?

"Jeff Faust" wrote in message news:ICEELEJLOALJHNHFDNIDEEJNDFAA.jeff@opticalres.com...

...
An exceptional case that happens with every run can hardly be called exceptional.

One should be wary of ideas that ring too nicely in the ear. [...]

8087

Age (days ago)

8089

Last active (days ago)

List overview

Download

11 comments

7 participants

participants (7)

Chris Russell
David Abrahams
Jeff Faust
Jeremy Siek
Mark Storer
Peter Dimov
Steve M. Robbins