<div dir="ltr">Interesting: the Orange Book on p. 396 states that if you press proceed in the full debugger, the result of the interrupted message send is assumed to be the result of the last expression that you evaluated (e. g. via print it) in the debugger. Or nil if you did not evaluate anything.<div><br></div><div>Seems to be no longer the case though. Also we have "return entered value" now.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Sa., 11. Apr. 2020 um 21:13 Uhr schrieb Jakob Reschke <<a href="mailto:forums.jakob@resfarm.de">forums.jakob@resfarm.de</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Think of this: you may not be able to reasonably proceed after an unresumable error without modifying the system or the context. But the IDE lets you do just that: you can change something on the stack in the debugger, or implement the missing method, then proceed and violà, you just reasonably proceeded from an otherwise unresumable error.<div><br></div><div>I suppose the methods you mentioned are recursive/repeating to allow for exactly that kind of workflow.<br><div><br></div><div>One should naturally be allowed to Proceed from the notifier window of a Halt or Warning.</div><div><br></div><div>Which leads us to the topic of exception-specific or context-specific buttons in the notifier once again. I don't remember which topic it was, but I wished for that already once during the last few months. Maybe it was the deprecation warnings and now we have an explanation how to deal with Warnings in the notifier and those text actions that allow to disable the warnings on the spot. And as always I'd like to point out that Common Lisp has a nice concept for responding to exceptions both automatically and interactively, with user-code-registered restart operations that can be invoked from the debugger: <a href="http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html" target="_blank">http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html</a> In Smalltalk you can already use #return, #retry, #resume etc in an exception handler, but you cannot access the handlers nicely from the debugger, and you cannot "resume somewhere along the way to the exception".</div><div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Sa., 11. Apr. 2020 um 16:38 Uhr schrieb Thiede, Christoph <<a href="mailto:Christoph.Thiede@student.hpi.uni-potsdam.de" target="_blank">Christoph.Thiede@student.hpi.uni-potsdam.de</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div id="gmail-m_4591617615410660794gmail-m_1478378149913241800gmail-m_8043908745088985445divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr">
<div id="gmail-m_4591617615410660794gmail-m_1478378149913241800gmail-m_8043908745088985445divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols" dir="ltr">
<p></p>
<div><span style="font-size:12pt">Just another thought: I see some confusion around the Proceed button in the debugger, and I felt the same confusion sometimes ago. Please forgive me for the sacrilege, but should we maybe question its general existence?</span></div>
<div><span style="font-size:12pt"><br>
</span></div>
<div><span style="font-size:12pt">Depending on the domain, it actually performs a mix of #retry (made possible by the quite </span><a href="http://forum.world.st/I-broke-the-debugger-td5110752.html#a5112307%23:~:text=recursively" style="font-size:12pt" target="_blank">confusing</a><span style="font-size:12pt"> recursive
implementation of Object >> #at:, Object >> #doesNotUnderstand: and others, I did not yet found any other motivation than the Proceed button to use recursion here) and ignore (#resumeUnchecked:, especially useful for UnhandledWarnings and Halts). Would it
be a reasonable goal to eliminate this button in the pre-debugger window and replace it with two buttons, Restart and Ignore? We could hide even hide the restart button if not appropriate (i.e., the exception is not an error).</span><br>
</div>
<div id="gmail-m_4591617615410660794gmail-m_1478378149913241800gmail-m_8043908745088985445Signature">
<div id="gmail-m_4591617615410660794gmail-m_1478378149913241800gmail-m_8043908745088985445divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div name="divtagdefaultwrapper">
<div>
<div id="gmail-m_4591617615410660794gmail-m_1478378149913241800gmail-m_8043908745088985445Item.MessagePartBody">
<div id="gmail-m_4591617615410660794gmail-m_1478378149913241800gmail-m_8043908745088985445Item.MessageUniqueBody" style="font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif,serif,EmojiFont">
<div dir="ltr">
<div id="gmail-m_4591617615410660794gmail-m_1478378149913241800gmail-m_8043908745088985445divtagdefaultwrapper"><font face="Calibri,Helvetica,sans-serif,EmojiFont,Apple Color Emoji,Segoe UI Emoji,NotoColorEmoji,Segoe UI Symbol,Android Emoji,EmojiSymbols">
<div id="gmail-m_4591617615410660794gmail-m_1478378149913241800gmail-m_8043908745088985445Signature">
<div style="margin:0px"><font style="font-family:Calibri,Arial,Helvetica,sans-serif,serif,EmojiFont">
<div><font size="3" color="black"><span style="font-size:12pt"><a href="http://www.hpi.de/" rel="noopener noreferrer" id="gmail-m_4591617615410660794gmail-m_1478378149913241800gmail-m_8043908745088985445LPNoLP" target="_blank"><font size="2"><span id="gmail-m_4591617615410660794gmail-m_1478378149913241800gmail-m_8043908745088985445LPlnk909538"><font color="#757B80"></font></span></font></a></span></font></div>
</font></div>
</div>
</font></div>
</div>
</div>
</div>
</div>
<div><font size="2" color="#808080"></font></div>
</div>
</div>
</div>
<div id="gmail-m_4591617615410660794gmail-m_1478378149913241800gmail-m_8043908745088985445divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols" dir="ltr">
<br>
</div>
What do you think?</div>
<div id="gmail-m_4591617615410660794gmail-m_1478378149913241800gmail-m_8043908745088985445divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols" dir="ltr">
And it would be great if anyone here could explain why Object >> #at: & Co. are recursive! :-)</div>
<div id="gmail-m_4591617615410660794gmail-m_1478378149913241800gmail-m_8043908745088985445divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols" dir="ltr">
<br>
</div>
<div id="gmail-m_4591617615410660794gmail-m_1478378149913241800gmail-m_8043908745088985445divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols" dir="ltr">
Best,</div>
<div id="gmail-m_4591617615410660794gmail-m_1478378149913241800gmail-m_8043908745088985445divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols" dir="ltr">
Christoph<br>
<br>
<div style="color:rgb(0,0,0)">
<hr style="display:inline-block;width:98%">
<div id="gmail-m_4591617615410660794gmail-m_1478378149913241800gmail-m_8043908745088985445divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> Squeak-dev <<a href="mailto:squeak-dev-bounces@lists.squeakfoundation.org" target="_blank">squeak-dev-bounces@lists.squeakfoundation.org</a>> im Auftrag von Thiede, Christoph<br>
<b>Gesendet:</b> Samstag, 11. April 2020 16:32 Uhr<br>
<b>An:</b> Chris Muller; The general-purpose Squeak developers list<br>
<b>Betreff:</b> Re: [squeak-dev] Why is ModificationForbidden not an Error?</font>
<div> </div>
</div>
<div>
<div id="gmail-m_4591617615410660794gmail-m_1478378149913241800gmail-m_8043908745088985445divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<p>Hi all! Thank you very much for having this interesting discussion :-)</p>
<p><br>
</p>
<p>@Chris:</p>
<p>> > <span style="font-size:12pt">-1. :-) Warnings are Notifications,</span></p>
<div>> As are Errors. Right?</div>
<div><br>
</div>
<div>Nope, sorry ;-)</div>
<div><img size="3449" id="gmail-m_4591617615410660794gmail-m_1478378149913241800gmail-m_8043908745088985445img99353" style="max-width: 99.9%;" src="cid:1716a994b4af456b1e51"> <img size="4270" id="gmail-m_4591617615410660794gmail-m_1478378149913241800gmail-m_8043908745088985445img899934" style="max-width: 99.9%;" src="cid:1716a994b4af456b1e52"><br>
</div>
<div><br>
</div>
<div>> <span>The two main use cases of ModificationForbidden present opposite perspectives onto it. For "protection from accidentally modifying a literal in a CompiledMethod", I understand the inclination to make it an Error. However, for the context of db
handling, [#markDirty + #resume] is normal processing, not an "error", and not even exceptional, either, so perhaps this is just a semantic irritation sensitivity on my part.. sorry. </span></div>
<div><br>
</div>
<div><span style="font-size:12pt">> </span><span style="font-size:12pt">But if they want to use ModificationForbidden for a Write Barrier, they'll probably want to extricate it from Error in the handler:</span><br>
</div>
<div>
<div>> </div>
<div>> [ myDbApp doStuff ]</div>
<div>> on: ModificationForbidden</div>
<div>> do:</div>
<div>> [ : forbidden |</div>
<div>> forbidden object beWritableObject.</div>
<div>> forbidden resumptionValue: forbidden retryModificationNoResume.</div>
<div>> forbidden resume: forbidden resumptionValue ]</div>
<div>> on: Error</div>
<div>> do: [ : err | myDbApp logErrorAndNotifyUser ]</div>
<div><br>
</div>
<div>
<div style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px">
This clarification was very helpful for me. I was not aware of your second use case before.</div>
<div style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px">
<br>
</div>
<div style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px">
<div style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px">
In my opinion, we are talking about two completely different use cases for the same exception.</div>
<div style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px">
<b>Literal protection</b> is a low-level error, comparable to out-of-bounds things and primitive failures. You almost never do want to ignore or fix them.</div>
<div style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px">
<b>Write barriers</b> for #markDirty, on the other hand, sound like a domain-specific topic to me that should neither raise an error, nor eventually signal an UnhandledError, but be resumed automatically (unless handled differently) by a #defaultAction that
removes the barrier (and additional handlers could, if desired, turn on some cache or so).</div>
<div style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px">
I have never dealt with Magma or any other DB framework for Smalltalk, but why do you (or would you) use these VM-based mechanisms for a high-level feature? Without knowing any details about your application, personally I would probably design an own exception
(DirtyModification?) for that purpose. This would allow you to clearly distinguish between low-level errors ("whoops, I just made an attempt to change a read-only code literal") and higher-level exceptions (DirtyModification). If we would follow my <a href="http://forum.world.st/The-Trunk-Kernel-eem-1317-mcz-td5113273.html#a5113433" target="_blank">proposal</a> to
raise ModificationForbidden from Object instead of Context, you could also consider to override #modificationForbiddenFor:at:put: in your database objects to raise DirtyModification instead of ModificationForbidden (in the same way as some classes override
#error or #primitiveError).</div>
<div style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px">
<br>
</div>
However, focusing again on the literal protection aspect, I still don't see when the current default #resume behavior of ModificationForbidden would be ever helpful. MF >> #resume calls Exception >> #resume: which does nothing more than to return resumptionValue!
When do we actually need this resumptionValue?</div>
</div>
<div><span style="font-size:12pt">Why can't we design MF like the following:</span><br>
</div>
<div><br>
</div>
<div>#resume - not possible, will signal IllegalResumeAttempt</div>
<div>#retryModification - retries the modification and returns nothing special</div>
<div>#forceModification: - makes the object to modify writable, retries the modification and, optionally, makes the object read-only again</div>
<div><br>
</div>
<div><span style="font-size:12pt">> </span><span style="font-size:12pt">If we don't want to break things (that are somehow </span><span style="font-size:12pt">wrong according to contemporary notion), we could make it a Warning in </span><span style="font-size:12pt">the
Squeak 5.x release stream and turn it into an error with Squeak </span><span style="font-size:12pt">6.0. That is: make it an Error today in Trunk, but if we would create </span><span style="font-size:12pt">a 5.4 release, we would have to remember changing
it back... :-/</span><br>
</div>
</div>
<div><span style="font-size:12pt"></span></div>
<div><span style="font-size:12pt"><br>
</span></div>
<div><span style="font-size:12pt">IIRC ModificationForbidden was introduced in 6.0alpha the first time?</span></div>
<div><br>
</div>
<div>Best,</div>
<div>Christoph</div>
<div><span style="font-size:12pt">
<div style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px">
<span style="font-size:12pt"></span></div>
</span></div>
<p></p>
<div id="gmail-m_4591617615410660794gmail-m_1478378149913241800gmail-m_8043908745088985445Signature">
<div id="gmail-m_4591617615410660794gmail-m_1478378149913241800gmail-m_8043908745088985445divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div name="divtagdefaultwrapper">
<div><font size="2" color="#808080"></font></div>
</div>
</div>
</div>
</div>
<hr style="display:inline-block;width:98%">
<div id="gmail-m_4591617615410660794gmail-m_1478378149913241800gmail-m_8043908745088985445divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> Squeak-dev <<a href="mailto:squeak-dev-bounces@lists.squeakfoundation.org" target="_blank">squeak-dev-bounces@lists.squeakfoundation.org</a>> im Auftrag von Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>><br>
<b>Gesendet:</b> Samstag, 11. April 2020 11:16:00<br>
<b>An:</b> Chris Muller; The general-purpose Squeak developers list<br>
<b>Betreff:</b> Re: [squeak-dev] Why is ModificationForbidden not an Error?</font>
<div> </div>
</div>
<div>
<div dir="auto">
<div dir="auto"></div>
In this case we might want specialized subclasses...
<div dir="auto"><br>
<div class="gmail_quote" dir="auto">
<div dir="ltr" class="gmail_attr">Le sam. 11 avr. 2020 à 03:45, Chris Muller <<a href="mailto:asqueaker@gmail.com" rel="noreferrer" target="_blank">asqueaker@gmail.com</a>> a écrit :<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">I think so, because if you try to use it for something else, it'll get entangled with your application's standard error handling. Regular apps have error handling like:
<div>
<div><br>
</div>
<div> [ myApp doStuff ] on: Error do: [ : err | myApp logErrorAndNotifyUser ]</div>
<div><br>
</div>
<div>and so for the use-case, <i>Protect CompiledMethod Literals from Accidental Modification</i>, inheriting from Error will allow the best backward compatibility with existing handlers.</div>
<div><br>
</div>
<div>But if they want to use ModificationForbidden for a <i>Write Barrier</i>, they'll probably want to extricate it from Error in the handler:</div>
<div><br>
</div>
<div> [ myDbApp doStuff ]</div>
<div> on: ModificationForbidden</div>
<div> do:</div>
<div> [ : forbidden |</div>
<div> forbidden object beWritableObject.</div>
<div> forbidden resumptionValue: forbidden retryModificationNoResume.</div>
<div> forbidden resume: forbidden resumptionValue ]</div>
<div> on: Error</div>
<div> do: [ : err | myDbApp logErrorAndNotifyUser ]</div>
<div><br>
</div>
<div>But now that I'm handling ModificationForbidden separately, what if I want <i>Protect CompiledMethod Literals from Accidental Modification</i>, too? I'm no longer handling correctly for that, because the handler has to assume they're signaled in the context
of the DB use case and not the Protection use case.</div>
</div>
<div><br>
</div>
<div> - Chris</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Apr 10, 2020 at 12:06 PM tim Rowledge <<a href="mailto:tim@rowledge.org" rel="noreferrer noreferrer" target="_blank">tim@rowledge.org</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
> On 2020-04-09, at 6:55 PM, Chris Muller <<a href="mailto:asqueaker@gmail.com" rel="noreferrer noreferrer" target="_blank">asqueaker@gmail.com</a>> wrote:<br>
> <br>
> The two main use cases of ModificationForbidden present opposite perspectives onto it.<br>
<br>
In that case perhaps we actually need two different signals? <br>
<br>
tim<br>
--<br>
tim Rowledge; <a href="mailto:tim@rowledge.org" rel="noreferrer noreferrer" target="_blank">
tim@rowledge.org</a>; <a href="http://www.rowledge.org/tim" rel="noreferrer noreferrer noreferrer" target="_blank">
http://www.rowledge.org/tim</a><br>
Useful random insult:- Has an inferiority complex, but not a very good one.<br>
<br>
<br>
<br>
</blockquote>
</div>
<br>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
</blockquote></div>
</blockquote></div>