More crash info.

[Zav - Alex Zavatone]

>on 5/5/03 7:36 PM, Zav - Alex Zavatone at zavpublic at mac.com wrote:
>
>>>  on 5/5/03 2:52 AM, Zav - Alex Zavatone at zavpublic at mac.com wrote:
>>>
>>>>>     OpenDataBase(myDB, myDBPath,1) -- CREATE DATABASE FROM SCRATCH
>>>>
>>>>   The above line instantly crashes Director if Valentina has
>>>>   (mistakenly or on purpose) not been inited.
>>>>
>>>>   Valentina should exit GRACEFULLY from such a condition.
>>>
>>>  Well, probably yes.
>>
>>  Can't you simply declare an  internal flag when the instance of the
>>  xtra is inited and check on an open database command?  If it fails,
>>  abort without crashing.  This might make V easier to learn and
>>  therefore get you new paying customers.
>
>:-)
>
>In fact you are first who have get into this trap.
>In the docs said by "big letters"
>
>     CALL ValentinaInit BEFORE ANY CALL to Valentina.

Yes but it is too easy to fall into that trap.  Macromedia paid me to 
break their software for 4 years.  Therefore, I have some experience 
in the field.  Point of fact:  It should not be this easy to break 
Valentina.  An xtra should not be an open minefield.  It should have 
SOME padding around the sharp edges if you know what I mean.

>Can you seat into a car, and do not insert a key?
>Will you car move after this?
>Even if you will press on Gas many times?  :-)
>
>Yes, you car do not explore on this mistake...

Yes but my car also does not explode.  Herein lies the difference.

>
>-----
>Zav, do you know why we have no such protection as you ask?
>
>Okay, you say: make flag and check it on open.
>But Zav, tomorrow somebody else will try call Cursor_Import() with call to
>Valentina init. Can this be? Yes.
>
>So it needs then, following by your logic add such check into EACH Valentina
>call. Agree?

If you trapped this on opendatabase, this would catch 99% of crash 
mistakes.  Then you would not need to trap this on every call.  Then 
you would have speed and safety.  Part of designing good software is 
how forgiving it is when things go wrong.  You don't have to 
parameter check on EVERY call, just the obvious ones.

>But this will slow down code in case of CORRECT program.
>We prefer speed. And reasonable error checks.

See above.

>
>>>  You need write scripts.
>>>  And later execute them.
>>>
>>>  Database do not like ANY mistake in steps.
>>>  So if you do this interactively you easy can do mistakes on some step.
>>>
>>>  Again, write scripts, and use DEBUGGER to see values of YOUR variables.
>>
>>  I do.  I don't understand what you are getting at.  I have to enter
>>  my commands in the message window to test my code.  I can't run the
>>  app from scratch all the time.
>
>Hmm, but you should.

Then coding takes forever.  I write my code modularly so I can test 
it that way.  When the app does not crash, this accelerates 
development and testing.

Thank you for your time.
-- 
- Zav
Kid tested. Mother Approved.