From: Robert Klemme <shortcutter@...>
Date: 2011-11-30T06:39:08+09:00
Subject: Re: Loading a faulty ruby file - forcing this

On Tue, Nov 29, 2011 at 5:45 PM, Marc Heiler <shevegen@linuxmail.org> wrote:
>> You could hook into Object#method_missing and
>> Object.const_missing to handle NameErrors before
>> they happen, although I'd try to redesign my code
>> in any possible way before resorting to such methods.
>
> Hmmm. My approach would only work easily if I'd
> be able to continue loading the whole ruby file
> in question. I am not sure I understood this solution
> well though - I have to handle NameErrors *before*
> they happen?
>
>> An exception always immediately stops execution at the
>> point where it is thrown and unwinds the stack until it
>> finds a handler (or the process terminates).
>
> Oh I see! Would be neat to be able to suppress that
> when one wants to, with the rest of the code continued
> to be read and interpreted.

You cannot do that because exception throwing code is written with the
knowledge that execution does *not* continue after the exception.  In
other words if the exception does not throw it is ensured code is in
proper state.  By suppressing exceptions code cannot rely on proper
state and might want to throw another exception later.

>> Basically you could wrap every individual section with
>> "begin rescue end". Then such a section would be the
>> smallest part which could fail. Alternatively you could
>> split the file in multiple parts and have a specific
>> implementation of "load" which ignores errors:
>
>> def load_ignorant(s)
>>  load(s)
>> rescue Exception
>>   # eat it
>> end
>
> Hmm you mean wrap the file into different smaller files
> and load these? Probably feasible. I'd however like to
> keep a constraint as in having a large ruby file available
> already. It also sounds like too much work to split the
> file in question up.
>
>> Why do you want to do that? That sounds like a bad plan
>> to me since you won't notice any issues and your
>> application's state is unclear.
>
> The demo code in question just shows that the ruby file
> only has invalid calls to non-existent methods. But
> otherwise, it is fine. I would argue that by definition
> there can not be any issues with it (from that faulty
> ruby file) because after all it is faulty anyway and
> there are only two states for it - either it contains
> valid ruby code or it is invalid (in which case it should
> be ignored).
>
> Consider it a crazy wish for purposely sloppy programming
> where perfection can stop at 40% rather than go for the
> usual 100%.
>
> As for the reason why I want to do that - I want to run
> invalid code which could become partially valid, rather
> than stopped when encountering an Exception.

Why?

> Consider it as something that will never find its way
> into any program.

If it exists, it will. :-)

> If it is too cumbersome to achieve though then this idea
> already falls short.

I do not think this is a good idea.  There was an article of a famous
author (might have been von Neumann) who said that the difference
between machines and natural systems is that we build machines so
errors show up as quickly as possible whereas nature tries to reduce
errors so systems can continue to work.

The semantic of a half valid piece of code is unknown.  Hence you
cannot rely on it doing what you intended it to do.

Kind regards

robert


-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/