Re: SmartEiffel shortcomings?

Roger Browne wrote:

>Lothar Scholz wrote:
>
>[1:]
>  
>
>>... If you use exception handling you
>>simply can't develop code anymore as you will not get any information
>>about the crashing position anymore.
>>    
>>
>
>Yeah, this limitation really stops us from taking full advantage of the
>power of Design by Contract. For my amber compiler I have two versions
>of the root class - one with exception handling and one without. If I
>get a contract failure I switch to the version without exception
>handling so that I can get my stack trace. Having to do that does suck a
>bit.
>
>  
>
When provided a STORABLE class and its supporting framewark
(namely some additions to the SE compiler) I added also print command
to the SE debugger. (Both, class STORABLE and the print command,
rely on object and class introspection, so it was straightforward
to apply to the debugger what had been developed for the class.)
Being on the way, I added more to the debugger, e.g. that it stops
at an exception before the stack gets unwound. The last version goes
still further: even if the system has not been compiled with -sedb
(and not with -boost) then a rudimentary debugger is invoked in case
of an exception. This way, you can (besides seeing the stack)
evaluate the heap.
Maybe this approach will be interesting for the SE1.2 developers.
See: http://www.cs.uni-potsdam.de/~wjansen/tar/persist_1_1.tgz

>[4:]
>  
>
>>A missing "storage" implementation.
>>    
>>
>
>Yeah. Something like this is more-or-less expected nowadays.
>
>  
>
Once again, I would like to contribute my STORABLE class
(ready for SE1.1) to SE1.2.

Regards
Wolfgang