[Glass] NOT storing errors in object log
Dale Henrichs
dale.henrichs at gemtalksystems.com
Fri Jun 27 09:36:29 PDT 2014
Mariano,
I guess I don't quite understand how the stacks are ending up in the object
log ...
The error handlers that stash continuations into the object log should be
the last "line of defense" where an unhandled error exception needs to
caught to prevent the gem process from being terminated ...
So for the #doesNotUnderstands that end up in object log, there must not
have been a proper handler ... if you handle an MNU then it should not end
up in any object log ...
A view of the stack structure would help me understand the problem in a bit
more detail
Dale
On Fri, Jun 27, 2014 at 7:14 AM, Mariano Martinez Peck <
marianopeck at gmail.com> wrote:
> Hi guys,
>
> I have an scenario, where I have a kind of processor object and some
> dynamic keys that represent actions. These actions are lookup somewhere and
> if found, they hold a closure which is executed by the processor. Many many
> times, several keys may not be found. The way the develop this is with a
> #doesNotUndertand: implemented in the processor.
>
> Anyway....the problem is that EACH key that is not found (and hence the
> #doesNotUnderstand: is called) is stored in the object log. So this has 2
> disadvantages:
>
> 1) When I want to debug something in the server (using gemtools) this is
> impossible because I have lots and lots of entries for these key not found
> expected errors.
> 2) I guess this also impacts in performance...
>
> I think I am using the WARemoteDebuggingWalkbackErrorHandler. I know how I
> can change that. But I do want to have the remote debugging stuff. I would
> just like to know if there is a hook or somehow I can disable this for a
> block closure execution or something.
>
> Thanks in advance,
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140627/75d05b9a/attachment.html>
More information about the Glass
mailing list