Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!dino!uxc.cso.uiuc.edu!garcon!garcon.cso.uiuc.edu!grunwald
From: grunwald@flute.cs.uiuc.edu (Dirk Grunwald)
Newsgroups: comp.lang.c++
Subject: Re: Exception handling and transaction management?
Message-ID: <GRUNWALD.89Jun24233938@flute.cs.uiuc.edu>
Date: 25 Jun 89 04:39:38 GMT
References: <546@voodoo.UUCP>
Sender: news@garcon.cso.uiuc.edu
Reply-To: grunwald@flute.cs.uiuc.edu
Distribution: usa
Organization: University of Illinois, Urbana-Champaign
Lines: 44
In-reply-to: bhagwan@voodoo.UUCP's message of 23 Jun 89 14:54:58 GMT


re: iterations

	basically, some linguistic concept that allows you to iterate
	over the contents of a class, e..g, a bag, a list, a whatever.

	while it's true that C++ doesn't have iterators, it's not clear
	that it needs them. Libg++ has the Pix (pseudo-index) class
	that resolves this problem (albeit, perhpas not as `nicely'
	as the iterators in clu).

	this is an important concept, but it's not clear that it needs
	linguistic methods to be possible.

re: exceptions	
	this, on the other hand, needs linguistic support. Basically,
	you want to say something like ``execute this <stuff>, and if
	you fail for some reason do this to recover''

	e.g., using the ``posit'' notation
	   posit
		open file
	   exception <read_only>
		print error message
		maybe signal another error
	   exception <no file descriptors left>
		close another open file & reloop

	exception handling can have either dynamic or static binding for
	exception names. you need to be able to ``unwind'' a stack when
	you've installed an exception handler.

	these aren't like signals in UNIX, because signals allow you to
	restart when you complete the signal handler. A formailism for
	that would be very nice too.

re: robust transaction processing
	mayhaps atomic actions? If you have exceptions & some concurrency
	mechanism, you can cover this up.


	
--
Dirk Grunwald -- Univ. of Illinois 		  (grunwald@flute.cs.uiuc.edu)