Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > When to use a garbage collector?

Reply
Thread Tools

When to use a garbage collector?

 
 
Jerry Coffin
Guest
Posts: n/a
 
      06-11-2008
In article <d9177235-e278-46e6-a709-cdac9bb80a53
@b1g2000hsg.googlegroups.com>, http://www.velocityreviews.com/forums/(E-Mail Removed) says...
> On 11 kesä, 19:43, (E-Mail Removed) wrote:
> > Seriously though, if you really didn't know what I meant with "throw,"
> > you should learn about exceptions.

>
> Exceptions are not logical. If construction of the object
> fails then what? The program fails also, usually. I never
> check anything, not since they invented exceptions, so
> I'm assuming that there are no exceptions


Oh my. In most cases you can do something reasonably productive when an
exception gets thrown. Even in the worst case, you probably want to
catch it and print out the most meaningful error message you can, which
is typically quite a bit more than the runtime library is likely to do
on its own.

--
Later,
Jerry.

The universe is a figment of its own imagination.
 
Reply With Quote
 
 
 
 
Stefan Ram
Guest
Posts: n/a
 
      06-11-2008
Jerry Coffin <(E-Mail Removed)> writes:
>Oh my. In most cases you can do something reasonably productive when an
>exception gets thrown. Even in the worst case, you probably want to
>catch it and print out the most meaningful error message you can


A function should not be coupled to an application more than
necessary, so that the function might be used in a library as well
(or one might even write functions for use in a library).

Usually, a function does not know which user interface the
program calling it employs. ::std::cout might be associated
with a console, or it might not be, when the application is GUI
based, web based or a driver or a service without a user interface.

So what should print out mean in the general case?
Should the function use ::std::cout << ... or what else to
print out the most meaningful error message it can?

 
Reply With Quote
 
 
 
 
Kai-Uwe Bux
Guest
Posts: n/a
 
      06-11-2008
Stefan Ram wrote:

> Jerry Coffin <(E-Mail Removed)> writes:
>>Oh my. In most cases you can do something reasonably productive when an
>>exception gets thrown. Even in the worst case, you probably want to
>>catch it and print out the most meaningful error message you can

>
> A function should not be coupled to an application more than
> necessary, so that the function might be used in a library as well
> (or one might even write functions for use in a library).
>
> Usually, a function does not know which user interface the
> program calling it employs. ::std::cout might be associated
> with a console, or it might not be, when the application is GUI
> based, web based or a driver or a service without a user interface.
>
> So what should print out mean in the general case?
> Should the function use ::std::cout << ... or what else to
> print out the most meaningful error message it can?


Of course, printing a message for the user is the last resort. We must
assume that all better ways of responding in a more specific way are
blocked (for whatever reason). In that case, at a point where you cannot
determine what "print out" means, you still have the option of letting the
exception propagate higher in the call stack. At some point, it has to be
known what "print out" means.


Best

Kai-Uwe Bux
 
Reply With Quote
 
Jerry Coffin
Guest
Posts: n/a
 
      06-11-2008
In article <(E-Mail Removed)-berlin.de>, (E-Mail Removed)-
berlin.de says...
> Jerry Coffin <(E-Mail Removed)> writes:
> >Oh my. In most cases you can do something reasonably productive when an
> >exception gets thrown. Even in the worst case, you probably want to
> >catch it and print out the most meaningful error message you can

>
> A function should not be coupled to an application more than
> necessary, so that the function might be used in a library as well
> (or one might even write functions for use in a library).
>
> Usually, a function does not know which user interface the
> program calling it employs. »::std::cout« might be associated
> with a console, or it might not be, when the application is GUI
> based, web based or a driver or a service without a user interface.
>
> So what should »print out« mean in the general case?
> Should the function use »::std::cout << ...« or what else to
> »print out« the most meaningful error message it can?


That's the whole point of using an exception: delaying handling of the
error until you reach a point at which it's apparent how it should be
handled. A decision that there's no alternative but to print an error
message and die is obviously the kind that's delayed the longest -- i.e.
you either handle an exception constructively or you allow it to
percolate up the stack (or maybe both).

At some point up the stack you reach a point at which the code knows the
environment in which it is executing, and therefore knows how to print
out an error message -- it might be a message window, or written to the
standard error stream, or written to a log file. In an embedded system,
it might just light up an LED or something on that order.

Asking me to predict the precise fashion of communication with the user
"in the general case" sounds a bit ridiculous, at least to me. As I said
previously, one of the strengths of exception handling is specifically
to allow such a decision to be delayed to the point that enough is known
about the specific environment to make such a decision. Asking me to
make such a decision ahead of time for every possible situation
obviously runs directly contrary to that.

--
Later,
Jerry.

The universe is a figment of its own imagination.
 
Reply With Quote
 
Jerry Coffin
Guest
Posts: n/a
 
      06-11-2008
In article <(E-Mail Removed)>,
(E-Mail Removed) says...

[ ... ]

> That's the whole point of using an exception: delaying handling of the
> error until you reach a point at which it's apparent how it should be
> handled.


Pardon me -- it's not really the _whole_ point, but merely part of the
point. Nonetheless, it's an important part of the point...

--
Later,
Jerry.

The universe is a figment of its own imagination.
 
Reply With Quote
 
Krice
Guest
Posts: n/a
 
      06-11-2008
On 11 kes, 20:33, Jerry Coffin <(E-Mail Removed)> wrote:
> Oh my. In most cases you can do something reasonably productive when an
> exception gets thrown.


Like what? If the object can't be constructed then there is
something seriously wrong and the program can't obviously
recover from that.

> Even in the worst case, you probably want to
> catch it and print out the most meaningful error message you can


"Error: object can't be constructed."
 
Reply With Quote
 
Bo Persson
Guest
Posts: n/a
 
      06-11-2008
Krice wrote:
> On 11 kes, 20:33, Jerry Coffin <(E-Mail Removed)> wrote:
>> Oh my. In most cases you can do something reasonably productive
>> when an exception gets thrown.

>
> Like what? If the object can't be constructed then there is
> something seriously wrong and the program can't obviously
> recover from that.


The task being performed might fail, but not the whole server.

>
>> Even in the worst case, you probably want to
>> catch it and print out the most meaningful error message you can

>
> "Error: object can't be constructed."


"Query result too large - please use a more specific selection"


Bo Persson


 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      06-11-2008
Jerry Coffin <(E-Mail Removed)> writes:
>Pardon me -- it's not really the _whole_ point, but merely part of the
>point. Nonetheless, it's an important part of the point...


The central point in the exception handling design was
the management of resources.

In particular, if a function grabs a resource how can the
language help the user to ensure that the resource is
correctly released upon exit even if an exception occurs?

from 6.4 Exception Handling in A History of C++: 1979 - 1991
by Bjarne Stroustrup

This might be related to the problem that a constructor can
not return a status code to indicate success or failure of the
construction as it is expected to return an object. Also, some
other functions that should return a value (like log) can
not return a status code. So some other means to convey the
status were required.

Ada83, and possibly already Algol68 and Clu had exceptions,
but I do not know who first came up with this concept.
Maybe it is inspired from processors, which might raise
interrupts, error signals or traps to invoke handlers.

 
Reply With Quote
 
Maik Beckmann
Guest
Posts: n/a
 
      06-11-2008
Jerry Coffin wrote:

> [ ... ]


Very interesting. Are there nice readings in the inet about this topic,
which include some C++ snippets for everday usage?


-- Maik
 
Reply With Quote
 
coal@mailvault.com
Guest
Posts: n/a
 
      06-11-2008
On Jun 11, 1:50*pm, "Bo Persson" <(E-Mail Removed)> wrote:
> Krice wrote:
> > On 11 kes, 20:33, Jerry Coffin <(E-Mail Removed)> wrote:
> >> Oh my. In most cases you can do something reasonably productive
> >> when an exception gets thrown.

>
> > Like what? If the object can't be constructed then there is
> > something seriously wrong and the program can't obviously
> > recover from that.

>
> The task being performed might fail, but not the whole server.
>


Yes, I think this sort of situation should be considered:

AccountBase
|
Account1_1
|
Account1_2

If the program is expecting to receive an Account1_2 object
over a network and a read fails/times out, I want to have the
object preserved as an Account1_1 if that much of the object
was successfully received. In baseball sometimes a hit is more
than a single, but not a double. If a runner tries to turn it
into a double he's thrown out. A double is better than a
single, but a single is much better than an out.

Brian Wood
Ebenezer Enterprises
www.webEbenezer.net
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Do you use a garbage collector (java vs c++ difference in "new") Arne Vajhj Java 12 04-13-2008 12:13 AM
Re: Do you use a garbage collector (java vs c++ difference in "new") Ian Collins Java 0 04-11-2008 02:41 AM
When to use Boehm-Demers-Weiser Garbage Collector? PengYu.UT@gmail.com C++ 0 03-30-2006 04:37 AM
Just Curious, What Kind Of Garbage Collector Does Sun's JVM Use? res7cxbi@verizon.net Java 2 01-06-2006 11:29 AM
Templates - Garbage In Garbage Not Out ramiro_b@yahoo.com C++ 1 07-25-2005 04:48 PM



Advertisments