Hi all,

You can signal an already signaled exception; the nested #signal will start searching for an exception handler from the most recently created exception handler.

I wonder if this is a legitimate and reasonable interpretation of ANSI's #signal:
Quote: The current exception environment is searched for an exception handler whose exception selector matches the signaled exception. The search proceeds from the most recently created exception handler to the oldest exception handler.

Repeated #signal would differ from #outer in that #outer starts serching for a handler from the current handler context and not from the most recently created handler context.

Here's a motivation example:

[1/0] on: Error do: [:ex | 
	[ex signal] on: ZeroDivide do: [Transcript show: #ZeroDivide]
	]

Would you expect this code to work and pick up the ZeroDivide handler?

Current implementation will ignore the ZeroDivide handler and open a debugger as the default action. It because currently a repeated signal is made equivalent to #outer.

If you agree with the above interpretation then The Inbox: Kernel-jar.1407 provides its implementation and Tests-jar.464 some tests.

The point or a use case is to provide additional (finer, more specific) handlers inside the general handler rather than wrap the general handler inside more specific handlers. More specific handlers can even be inside a method so the readability would not degrade.

Here's a simple example:

[1/o] on: Error do: [:ex | 
	[[ex signal] 
		on: ZeroDivide do: [Transcript show: #ZeroDivide]]
		on: MessageNotUnderstood do: [Transcript show: #MNU]
	]

or even

 [1/o] on: Error do: [:ex | self dissect: ex]

instead of 

[[1/o] 
	on: ZeroDivide do: [Transcript show: #ZeroDivide]]
	on: MessageNotUnderstood do: [Transcript show: #MNU]


Does this make sense?

Thanks for your opinion.


best, 
Jaromir
^[^    
  --
Sent from Squeak Inbox Talk