Plaster
New
List
Login
text
apl
aspx
asterisk
brainfuck
c
c++hdr
c++src
cassandra
ceylon
clojure
clojurescript
cmake
cobol
coffeescript
common-lisp
crystal
csharp
css
cypher-query
cython
d
dart
diff
django
dockerfile
dylan
ebnf
ecl
ecmascript
edn
eiffel
ejs
elm
erb
erlang
ez80
factor
fcl
feature
forth
fortran
fragment
gfm
go
gql
groovy
gss
haml
handlebars-template
haskell
haxe
hive
html
http
httpd-php
httpd-php-open
hxml
ini
java
javascript
json
jsp
jsx
julia
kotlin
latex
less
literate-haskell
lua
mariadb
markdown
mbox
mirc
mscgen
msgenny
mssql
mumps
mysql
n-triples
nesc
nginx-conf
nsis
objectivec
octave
oz
pascal
perl
pgp
pgp-keys
pgp-signature
pgsql
php
pig
plsql
properties
protobuf
puppet
python
q
rpm-changes
rpm-spec
rsrc
ruby
rustsrc
sas
sass
scala
scheme
scss
sieve
slim
smarty
solr
soy
sparql-query
spreadsheet
sql
squirrel
stex
styl
swift
systemverilog
tcl
textile
tiddlywiki
tiki
tlv
tornado
ttcn-asn
ttcn-cfg
turtle
twig
typescript
typescript-jsx
vb
vbscript
velocity
verilog
vertex
vhdl
vue
webidl
xml
xml-dtd
xquery
xu
yaml
z80
default
Visibility:
public
unlisted
private
;;; CLHS 9.1.4 Signaling and Handling Conditions ;;; ;;; http://www.lispworks.com/documentation/HyperSpec/Body/09_ad.htm ;;; ;;; > Once a handler in a handler binding form (such as HANDLER-BIND or ;;; > HANDLER-CASE) has been selected, all handlers in that form become inactive ;;; > for the remainder of the signaling process. While the selected handler ;;; > runs, no other handler established by that form is active. That is, if the ;;; > handler declines, no other handler established by that form will be ;;; > considered for possible invocation. ;;; CLHS HANDLER-BIND ;;; ;;; http://www.lispworks.com/documentation/HyperSpec/Body/m_handle.htm#handler-bind ;;; ;;; > If more than one handler binding is supplied, the handler bindings are ;;; > searched sequentially from top to bottom in search of a match (by visual ;;; > analogy with typecase). If an appropriate type is found, the associated ;;; > handler is run in a dynamic environment where none of these handler ;;; > bindings are visible (to avoid recursive errors). If the handler declines, ;;; > the search continues for another handler. ;;; ;;; > If no appropriate handler is found, other handlers are sought from ;;; > dynamically enclosing contours. If no handler is found outside, then ;;; > signal returns or error enters the debugger. (defun printer (thing) (lambda (&rest args) (declare (ignore args)) (print thing))) (handler-bind ((simple-condition (printer "First")) (condition (printer "Second"))) (signal "Test")) ;;; >> First ;;; >> Second ;;; => NIL ;;; TODO: Given all of the above, how is this behavior of HANDLER-BIND correct? ;;; ;;; CLHS 9.1.4 says: ;;; ;;; > That is, if the handler declines, no other handler established by that ;;; > form will be considered for possible invocation. ;;; ;;; But this is not what we see, as both handlers have been called. ;;; ;;; CLHS HANDLER-BIND says: ;;; ;;; > If more than one handler binding is supplied, the handler bindings are ;;; > searched sequentially from top to bottom in search of a match (by visual ;;; > analogy with typecase). ... If the handler declines, the search continues ;;; > for another handler. If no appropriate handler is found, other handlers ;;; > are sought from dynamically enclosing contours. ;;; ;;; This does describe the behavior that we see. The "search" in the quoted ;;; paragraph refers to finding the appropriate handler within that single ;;; HANDLER-BIND. So when it says "the search continues", it's referring to ;;; examining other handlers within that same HANDLER-BIND. However, doesn't ;;; this directly contradict what CLHS 9.1.4 says?