[Seaside-dev] WAExceptionHandlerTest>>testHandlesReturnBool

[Julian Fitzell]

On Mon, Jun 15, 2009 at 12:14 PM, Michael
Lucas-Smith<mlucas-smith at cincom.com> wrote:
> Hi,
>
> The test in question is this:
>
> testHandlesReturnsBool
>   self
>       assertHandles: WATestError new
>       returnsSatisfying: [ :result | result == true or: [ result == false ]
> ].
>   self
>       assertHandles: nil
>       returnsSatisfying: [ :result | result == true or: [ result == false ]
> ]
>
> assertHandles: anObject returnsSatisfying: aBlock
>   | result instanceResult |
>   result := self handlerClass handles: anObject.
>   instanceResult := self createHandler handles: anObject.
>   self assert: result = instanceResult.
>   self assert: (aBlock value: result)
>
> In VisualWorks, GenericException class>>handles: aSignalledException is
> implemented as:
>
>   ^self accepts: aSignalledException creator
>
> It's a method that you really "shouldn't get to" without aSignalledException
> being a real signallable object. The question was raised by another engineer
> here as to why we would want to make this method do a type-check if it's
> never practically put in the situation created by the test case.
>
> I tend to agree with his assessment, which is why I'm raising it here.. I'd
> like to remove the second clause since it's not an execution scenario
> Seaside would ever have to care about.
>
> Is that okay?

Hmm... looks pretty suspicious, alright. The ANSI spec specifies that
the parameter to #handles: is an exceptionDescription, which nil
certainly is not. I'd like to think I had a good reason for writing
that part of the test (I checked and I did write it) but unfortunately
it's already there in my first commit and the previous versions in my
image don't reveal any good reason for adding that part.

In the absence of any perceivable reason for its inclusion, I think we
have to assume I was being overly thorough and tested that just
because it worked on Squeak. I think you can take the "nil" part
out...

Julian