Smalltalk › Cincom › VisualWorks

RE: Exception stack curtailment.

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

Mark Plas

RE: Exception stack curtailment.

Hi Antony,

I'm not sure what you mean but when I execute this (<print it>):

[#(1 2) do: [:i | self error: 'test']]
on: Error
do: [:ex |
| cnt startContext str |
startContext := ex initialContext.
cnt := 0.
str := WriteStream on: String new.
[startContext notNil and: [cnt < 10]] whileTrue:
[startContext printOn: str. str cr.
startContext := startContext sender.
cnt := cnt + 1].
str contents ]

I get a stack trace containing everything from where the exception was
raised:

UndefinedObject(Object)>>error:
optimized [] in [] in UndefinedObject>>unboundMethod
Array(SequenceableCollection)>>do:
optimized [] in UndefinedObject>>unboundMethod
BlockClosure>>on:do:
UndefinedObject>>unboundMethod
UndefinedObject(Object)>>performMethod:arguments:
UndefinedObject(Object)>>performMethod:
...

The stack hasn't been curtailed and the exception raised by 'self error:
'test'' isn't resumable.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Antony Blakey
Sent: woensdag 11 juli 2007 11:45
To: VW-Development List; VWNC
Subject: Exception stack curtailment.

Hi,

I'm trying to log exception stack traces in a server application. If
I do this:

[ .. handle request ... ] on: Error do: [ :ex | ex ... ]

then I get no joy because the exception in ex has had it's stack
curtailed by #performHandler: - unless it's resumable, but I need the
stack of *all* exceptions. I'm not clear on the meaning of the
<exception: ...> pragmas. Does anyone know of some mechanism I can
use to capture the exceptions thrown in a block without losing the
context chain of the exception? It's not obvious looking at the code,
and the VW documentation doesn't help in this case.

Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

You can't just ask customers what they want and then try to give that
to them. By the time you get it built, they'll want something new.
-- Steve Jobs

Dave Stevenson-2

Re: Exception stack curtailment (in HttpServerStreams)

> The fact that your code works makes me suspect that crossing a
process boundary may be responsible for clearing the sender on each
context.

Forking creates a new process whose initial context has a sender of nil,
and whose subsequent contexts are created from evaluating the forked
block. If the new context linked back into the spawning process, then it
would be a copy of the original, not a new spawn, and all kinds of bad
things would happen. So with this in mind it is reasonable that the base
system does not provide the ability to trace execution across process
boundaries. Not that one couldn't implement some tricks to achieve that
kind of behavior, but the effort may be more than the gain, given the
complexity it would introduce.

Dave

Antony Blakey wrote:

>
> And that works for me ... what's misleading though is that this:
>
> [ #(1 2) do: [:i | self error: 'test'] ] on: Error do: [ :ex | ex
> inspect ].
>
> will show that ex initialContext sender is nil.
>
> And the reason I was exploring this was that code like this:
>
> [self recordWalkback: (self getWalkbackFrom: exception)] fork.
>
> which is in HttpServerStreams, was also only dumping the top of the
> stack, even thought it also walks the context sender chain.
>
> The fact that your code works makes me suspect that crossing a process
> boundary may be responsible for clearing the sender on each context. I'm
> presuming that the inspector is in a different process. For example, this:
>
> [ #(1 2) do: [:i | self error: 'test'] ]
> on: Error
> do: [:ex |
> [ | cnt startContext str |
> startContext := ex initialContext.
> cnt := 0.
> str := WriteStream on: String new.
> [startContext notNil and: [cnt < 10]] whileTrue:
> [startContext printOn: str. str cr.
> startContext := startContext sender.
> cnt := cnt + 1].
> str contents inspect
> ] fork
> ]
>
> doesn't work, whereas it does without the fork.
>
> In any case, mystery solved
>
> On 11/07/2007, at 7:43 PM, Mark Plas wrote:
>
>> [#(1 2) do: [:i | self error: 'test']]
>> on: Error
>> do: [:ex |
>> | cnt startContext str |
>> startContext := ex initialContext.
>> cnt := 0.
>> str := WriteStream on: String new.
>> [startContext notNil and: [cnt < 10]] whileTrue:
>> [startContext printOn: str. str cr.
>> startContext := startContext sender.
>> cnt := cnt + 1].
>> str contents ]
>
> Antony Blakey
> -------------
> CTO, Linkuistics Pty Ltd
> Ph: 0438 840 787
>
> Did you hear about the Buddhist who refused Novocain during a root canal?
> His goal: transcend dental medication.
>
>
>

Terry Raymond

RE: Exception stack curtailment (in HttpServerStreams)

Not quite true.

If you look at BlockClosure>>promiseBlock: and class Promise you will
see how cross process exceptions can be addressed.

Terry

===========================================================
Terry Raymond
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI 02878
(401) 624-4517 [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================

> -----Original Message-----
> From: Dave Stevenson [mailto:[hidden email]]
> Sent: Wednesday, July 11, 2007 1:00 PM
> To: Antony Blakey
> Cc: VW-Development List; VWNC
> Subject: Re: Exception stack curtailment (in HttpServerStreams)
>
> > The fact that your code works makes me suspect that crossing a
> process boundary may be responsible for clearing the sender on each
> context.
>
> Forking creates a new process whose initial context has a sender of nil,
> and whose subsequent contexts are created from evaluating the forked
> block. If the new context linked back into the spawning process, then it
> would be a copy of the original, not a new spawn, and all kinds of bad
> things would happen. So with this in mind it is reasonable that the base
> system does not provide the ability to trace execution across process
> boundaries. Not that one couldn't implement some tricks to achieve that
> kind of behavior, but the effort may be more than the gain, given the
> complexity it would introduce.
>
> Dave
>
> Antony Blakey wrote:
> >
> > And that works for me ... what's misleading though is that this:
> >
> > [ #(1 2) do: [:i | self error: 'test'] ] on: Error do: [ :ex | ex
> > inspect ].
> >
> > will show that ex initialContext sender is nil.
> >
> > And the reason I was exploring this was that code like this:
> >
> > [self recordWalkback: (self getWalkbackFrom: exception)] fork.
> >
> > which is in HttpServerStreams, was also only dumping the top of the
> > stack, even thought it also walks the context sender chain.
> >
> > The fact that your code works makes me suspect that crossing a process
> > boundary may be responsible for clearing the sender on each context. I'm
> > presuming that the inspector is in a different process. For example,
> this:
> >
> > [ #(1 2) do: [:i | self error: 'test'] ]
> > on: Error
> > do: [:ex |
> > [ | cnt startContext str |
> > startContext := ex initialContext.
> > cnt := 0.
> > str := WriteStream on: String new.
> > [startContext notNil and: [cnt < 10]] whileTrue:
> > [startContext printOn: str. str cr.
> > startContext := startContext sender.
> > cnt := cnt + 1].
> > str contents inspect
> > ] fork
> > ]
> >
> > doesn't work, whereas it does without the fork.
> >
> > In any case, mystery solved
> >
> > On 11/07/2007, at 7:43 PM, Mark Plas wrote:
> >
> >> [#(1 2) do: [:i | self error: 'test']]
> >> on: Error
> >> do: [:ex |
> >> | cnt startContext str |
> >> startContext := ex initialContext.
> >> cnt := 0.
> >> str := WriteStream on: String new.
> >> [startContext notNil and: [cnt < 10]] whileTrue:
> >> [startContext printOn: str. str cr.
> >> startContext := startContext sender.
> >> cnt := cnt + 1].
> >> str contents ]
> >
> > Antony Blakey
> > -------------
> > CTO, Linkuistics Pty Ltd
> > Ph: 0438 840 787
> >
> > Did you hear about the Buddhist who refused Novocain during a root
> canal?
> > His goal: transcend dental medication.
> >
> >
> >