on 7/29/02 11:34 PM, Will Leshner at leshner at ljug dot com wrote:
> The downside is that exceptions are things that work in RB as long as RB
> is working. When you get a failed assertion it means that RB isn't
> working anymore, so there is no way that exceptions can be reliable.
>
> We seem to love car analogies, so here's one. On my car if I'm really
> low on gas a light comes on. That's kind of like my car is throwing a
> low-gas exception. But if I get into an accident and my car is
> destroyed, then I shouldn't be surprised if the light doesn't come on
> even though all my gas has dribbled out of the tank. A failed assertion
> is kind of like RB having a major car accident.
Well, it makes no difference whether RB crashes or not (it will eventually
anyhow), the only reason we would need this is to help us avoid a type of
code that can lead to this failure assertion so we don't have to wait for RS
to fix it.
Basically, it lets you know where the error occurred, but don't care about
the crash shortly afterward.
The majority of failure assertions (that are in built apps also, not the IDE
only kind) I get doesn't crash the app until repeated many times or
something is done.
Some of the ones that do crash immediately after pressing continue sometimes
doesn't always crash immediately after, and might even run fine for a few
minutes (gives you just enough time to see where the error occurred with the
failure assertion exception).
The point of this feature is not to avoid/hide the failure dialog from the
user, but rather to help you track down on those nasty failure assertions so
that we can avoid the code that's causing it or find a work around. This
will also help us provide a better detail about the failure assertion to RS
because we have a better understanding of why it happens.
Regards,
Lo Saeteurn
|