From: "Michael T. Richter" Date: 2008-06-14T19:43:19+09:00 Subject: Re: raise and rescue --=-X3qFlAkhjvs9JCZzu7q2 Content-Type: multipart/alternative; boundary="=-ZOsH/wyXczT6/l47jNUs" --=-ZOsH/wyXczT6/l47jNUs Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2008-06-14 at 06:09 +0900, Robert Klemme wrote:=20 > There is no way - and for good reason. An exception is thrown because=20 > execution cannot proceed at that line. This is not a "good reason". Having used languages with restartable exceptions I can pretty much guarantee you that it is not only possible, but often desirable to have restartable exceptions. Consider this use case: 1. The software commences a procedure that is time-consuming and that requires lots of memory. 2. In the middle of this it runs out of memory. An exception is raised. In the Ruby (and many other languages) world, I'm boned. I have to throw away all the time and memory spent to get where I am, free up memory in some way, and then restart the whole thing. This could be a non-trivial operation (and, indeed, for this use case, is defined as such). In a world with restartable exceptions, however, the use case continues thus: 3. The exception handler pops up a dialogue/prompt/whatever telling me that memory is low. It suggests actions I can take to free up enough memory. Let's say I choose to kill memory hogs like Firefox or OpenOffice.org. I click "continue" (or type or whatever the UI is). 4. The exception handler retries the very line of code that failed. All of the expensive, time-consuming setup that led to that point is still there and still ready for action. (Please note at this point that this is only one example. I could probably, given an hour, come up with a hundred situations in which restartable exceptions are useful and desirable. Too, the handler's actions are only one of a thousand possible reactions it could have. Maybe for efficiency's sake I'm memoizing a whole bunch of calculations. If I run out of memory in this case, the handler could clear the LRU memo cache entries for twice the amount of reported memory being claimed as a quick heuristic. This would be totally transparent to the user except for a slight hiccough in performance.) Now it is possible in the Ruby model to partition things in many situations such that a retry only executes a small amount of code instead of the huge setup alluded to above. This is a problem, however, for several reasons: 1. You're putting in unnecessary scaffolding code solely because of the language's shortcomings. (Shades of C++ and Java here, albeit very, very, very minuscule shades.) This clutters code, constrains architecture and generally is, to my eyes, anti-Ruby. 2. Not all problems can be built this way. For those problems which cannot be set up this way, you're boned. 3. Most importantly, you're constraining your very thinking about problems. There will be approaches to problems you simply will not think of because the very language conspires against your thinking down those lines. --=20 Michael T. Richter (GoogleTalk: ttmrichter@gmail.com) Politics is the art of looking for trouble, finding it whether it exists or not, diagnosing it incorrectly, and applying the wrong remedy. (Ernest Benn) --=-ZOsH/wyXczT6/l47jNUs Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sat, 2008-06-14 at 06:09 +0900, Robert Klemme wrote:=20

There is no way - and for good reason.  An exceptio=
n is thrown because 
execution cannot proceed at that line.

This is not a "good reason". Having used languages with res= tartable exceptions I can pretty much guarantee you that it is not only pos= sible, but often desirable to have restartable exceptions. Con= sider this use case:

1. The software commences a procedure that is time-consuming and that requi= res lots of memory.
2. In the middle of this it runs out of memory. An exception is raise= d.

In the Ruby (and many other languages) world, I'm boned. I have to th= row away all the time and memory spent to get where I am, free up memory in= some way, and then restart the whole thing. This could be a non-triv= ial operation (and, indeed, for this use case, is defined as such).&= nbsp; In a world with restartable exceptions, however, the use case continu= es thus:

3. The exception handler pops up a dialogue/prompt/whatever telling me that= memory is low. It suggests actions I can take to free up enough memo= ry. Let's say I choose to kill memory hogs like Firefox or OpenOffice= .org. I click "continue" (or type or whatever the UI is). 4. The exception handler retries the very line of code that failed. A= ll of the expensive, time-consuming setup that led to that point is still t= here and still ready for action.

(Please note at this point that this is only one example. I could pro= bably, given an hour, come up with a hundred situations in which restartabl= e exceptions are useful and desirable. Too, the handler's actions are= only one of a thousand possible reactions it could have. Maybe for e= fficiency's sake I'm memoizing a whole bunch of calculations. If I ru= n out of memory in this case, the handler could clear the LRU memo cache en= tries for twice the amount of reported memory being claimed as a quick heur= istic. This would be totally transparent to the user except for a sli= ght hiccough in performance.)

Now it is possible in the Ruby model to partition things in many situations= such that a retry only executes a small amount of code instead of the huge= setup alluded to above. This is a problem, however, for several reas= ons:

1. You're putting in unnecessary scaffolding code solely because of the lan= guage's shortcomings. (Shades of C++ and Java here, albeit very, very= , very minuscule shades.) This clutters code, constrains architecture= and generally is, to my eyes, anti-Ruby.
2. Not all problems can be built this way. For those problems which c= annot be set up this way, you're boned.
3. Most importantly, you're constraining your very thinking about pr= oblems. There will be approaches to problems you simply will not thin= k of because the very language conspires against your thinking down those l= ines.

--
Michael T. Richter <ttmri= chter@gmail.com> (GoogleTalk: ttmrichter@gmail.com)
Politics is the art of looking for trouble, finding it whether it exists= or not, diagnosing it incorrectly, and applying the wrong remedy. (Ernest = Benn)

--=-ZOsH/wyXczT6/l47jNUs-- --=-X3qFlAkhjvs9JCZzu7q2 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIU6DcLqyWkKVQ54QRAmpGAJ90xfJldjqomtaXfMY1kObN0KN9vACfXWPB O5kb/aiaJe15CuTMjbey6co= =N6T7 -----END PGP SIGNATURE----- --=-X3qFlAkhjvs9JCZzu7q2--