[Nitro] Error Reporting WAS: Re: [PATCH] Og patches
Jonathan Buch
john at oxyliquit.de
Mon May 7 05:07:32 EDT 2007
Hi,
> As an aside... this is not so much Nitro, but a common theme in dynamic
> language frameworks...
this is slightly ot, but nontheless a very good discussion. :)
> The dynamic stuff is a necessary but double-edged sword. It's the
> lever that gives Nitro its force. But the dynamically constructed
> application doesn't seem straightforward to debug. At a certain level
> the stack trace dumps are hard to correlate back to any particular code
> as loaded from disk.
Yeah, this is most true, especially at 2 areas: Og relations and Nitro
templates. Good error reporting is one of the hardest things to do in
a framework.
> Would it be possible to use more of the annotation information, or add
> more annotation information, to provide better stack traces, or a
> switch that injects optional local variables with state information when
> running in debug mode?
Well, there's a few points where it's just impossible to get 'more info'.
One of that is using eval(). Hm... speaking of that, file and line can be
given to the eval functions, have to check that.
Ahh.. yeah, well, expect next release to have at least better stack
traces when something in the Og relations goes bad. :)
But, preferably, stack traces should always point to your own code, not
to Nitro/Og. ;D Code digging isn't everyones favourite hobby, and
having to dig into a whole framework might scare people off a little.
So, what would be best, more checks everywhere + custom error classes?
> I realize this is more of a ruby question than a Nitro question, and may
> be more indicative of my ignorance than any language or Nitro
> limitation. If so, I'm sorry for the interruption...
The Nitro ML is so low volume, don't hesitate to write. ;) And your
post pointed some things out which could be made better in Nitro,
which is always a good thing. And, any mail to Nitro ML is a motivation
'refreshment' for me to work on Nitro/Og. :)
> But if this is a valid point, then... since ease of use includes ease of
> debugging, then I think improved stack trace information will speed
> Nitro's rate of uptake and adoption. I see it as an enhancement for
> 0.60 or 0.70 ;)
I'll make a patch ready for Og in the next days, that at least will go
into the next release.
Jo
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
More information about the Nitro-general
mailing list