[Nitro] OG RFC: Catching an early/fatal exception.
Mark Van De Vyver
mvyver at gmail.com
Wed Sep 19 09:19:53 EDT 2007
George, now you'll understand why I had no idea about what the effect
of that last patch was :)
Also, try and uncover this without a reasonable debugger :)
You're writing a spec, an Og object is defined at the same 'level' as
the describe's. 'Og.start' is run.
The 'query' call in the first call to sql.rb:create_field_map,
generates an exception.
NOTE: We are within the 'unless map =
sql.rb:handle_sql_exception() is called and a new StoreException is raised.
That StoreException is never caught.
The Og.start returns silently.
There is still a connection open to the DB backend, the DB backend is untouched.
manager.rb:put_store is entered, @pool is undefined, and it is from
_here_ that we return to og.rb:start where the exception is _logged_,
but not raised.
So we've seen a fatal error, the spec never receives an exception -
just the Og.start returning 'nil', with a DB connection open and
classes still 'managed'.
Your hint that something is not right might be a later exception:
Error message: database is locked(database is locked)
And off you go on that tangent :)
Anyway, I digress.....
1) Where should these exceptions be handled?
There are three places this exception could be handled:
d) both a) and b)
2) What should be done with the DB connection and the manged classes?
>From my understanding, because
'klass.instance_variable_get("@field_map")' returned nil/false in
sql.rb:create_field_map we should really shutdown the DB connection,
unmanage the classes, and scream blue-murder. The unmanage classes
step is because I think Og's manger doesn't like being given the same
class twice - but this might be an impression left from the OGTABLE
warning just patched? Anyway, safety first, and I'd vote for
something like the following somewhere (where?) in 1 d):
if manager.close_store == nil && manager.unmanage_classes == 
More information about the Nitro-general