How does Smalltalk handle a program error?

Question

I am new to Smalltalk. I read some articles and documents about this, and I am surprised at its fullness of concepts. And he offers some kind of live debugging.

In any case, for program errors, an error means that the program logic is incorrect, and all accumulated mutations by the program are all invalid. To ensure integrity, the entire program must be restarted from some point, and the entire state of the program must be rolled back.

How does Smalltalk do it? (perhaps this question can be applied to all dynamic REPL languages ​​...)

Answer 1

Smalltalk uses Exception objects. I recommend that you read the chapter on https://gforge.inria.fr/frs/download.php/26600/PBE2-Exceptions-2010-03-02.pdf

this is part of a Pharo book on examples: http://pharobyexample.org/

As for mutation, debugging, etc., note that Smalltalk describes a lot of material in this language. For example, the MethodContext class. These objects redefine the method contexts that the VM executes. This way you can test them and play with them like regular objects. Same thing with CompiledMethod. Just for fun, check the "pseudo" variable "thisContext" :)

If you want to answer your answers yourself, take a look at the Debugger class. So, you want to know what happens when you restart the method in the middle of the debugger? then review the #restart method in Debugger and follow these steps :)

Answer 2

You ask, in essence, “how can this whole computer return to a known state?” Because the Smalltalk image is a virtual machine in the same sense as VMWare and VirtualBox.

The closest we have to the ability to reverse arbitrary side effects (excluding obvious impossibilities such as rolling back I / O) is probably Alessandro Wart Mira, as described in his doctoral dissertation, Experimenting with Programming Languages . At least in a general sense: of course, you can use things like the Memento and Command templates to implement canceled operations.

Answer 3

I assume that you mean a lot of objects in the image that can go into a conflicting state when developing and debugging. The usual procedure is to store the code in packages such as (Monticello for squeak / pharo). When you want to reset things, you will get a clean image from the distribution code and reloads from the packages. For deployed applications, in addition to the code in packages, information is usually required to recreate your data objects stored in some external form, such as a serialized form stored in files, or in a dql or noSql database. Thus, your reset procedure will take a new image, load code from packages, load data model objects from external storage.

Answer 4

This is not true!

Of the small mailboxes that I know, none of them support this kind of transaction. All side effects that accumulate during execution are set. There is no automatic rollback. Research is being done on how to maintain this, but nothing to try AFAIK. This is what you need to know if you are debugging and returning to the stack trace that the objects are not in the state in which they were at run time. You see only objects in their latest state.

Although it is not easy to support it in a general way, there are some possibilities for solving this problem with the design of your program. The most famous approaches:

• you copy / clone the objects you want to change, and apply the changes to the copies. If something goes wrong, you just throw away the copies. If everything is in order, you apply the contents of the copies to the originals. You can solve this using a memory pattern.
• you apply the changes to your objects, but if something went wrong, you reapply the original content. This can be implemented using do / undo actions using the command template.