OpenEuphoria

1. Request for feature

• Posted by Greg Haberek <ghaberek at gm?il.?om> Dec 26, 2007
• 502 views

I'd like to see a crash() routine that forcibly crashes the app, dead in its
tracks. Currently, I see most people are using }}}
<eucode>? 1/0</eucode>
{{{
 to force a
divide by zero to crash. But I'd like to see something like:

if i = 5 then
  crash( "I couldn't possibly be five!\n" )
end if

This then triggers the normal series of crash_message, crash_routine, etc. It's
much prettier IMHO and would produce a correct ex.err file, like this:

C:\EUPHORIA\myfile.exw:1234 in procedure dosomething()
I couldn't possibly be five!

Just my thoughts...

-Greg

3. Re: Request for feature

• Posted by CChris <christian.cuvier at ?gricu?ture.gouv.fr> Dec 27, 2007
• 499 views

Derek Parnell wrote:
> 
> Greg Haberek wrote:
> > I'd like to see a crash() routine that forcibly crashes the app ...
> 
> This has my support.
> 
> Maybe the existing abort() routine can do this as it already ends a program
> immediately. If passed a string rather than an integer it would do the trace
> dump and ex.err thing then end the program.
> 
> e.g.
> }}}
<eucode>
> if i = 5 then
>     abort("I can't possibly be five")
> end if
> 
> 
> -- 
> Derek Parnell
> Melbourne, Australia
> Skype name: derek.j.parnell

Sure, abort() is here already, so let's extend it:
* abort(msg_string) would display msg_string and do an abort(-1);
* abort({string,ret_val}) would display msg_string and do an abort(ret_val).

How about that?
CChris

5. Re: Request for feature

• Posted by Pete Lomax <petelomax at ?luey?nder.co.uk> Dec 27, 2007
• 479 views

CChris wrote:
> Sure, abort() is here already, so let's extend it:
> * abort(msg_string) would display msg_string and do an abort(-1);
> * abort({string,ret_val}) would display msg_string and do an abort(ret_val).
>
> How about that?

You may have missed the point about the ex.err?

My take: In the simple case, program A is run stand-alone:

abort(n)     terminates the program quietly, no ex.err, as now.
abort("msg") terminates the program much as ?9/0. Currently it does almost 
              _exactly_ what is desired except that the ex.err contains
              "argument to abort() must be an atom", and it seems logical
              to replace that with "msg" (a tiny change?). [see also PS]

The other case to consider is when program B performs an exec or system_exec of
program A and determines the exit code. Four possibilities now present:

1) normal termination or abort(0).
2) a standard error such as divide by zero.
3) abort(n) where n!=0.
4) [new] abort("msg").

The first point that strikes me here is that program B can only distinguish
abort(1) from case 2) by looking for the presence/date&timestamp/contents of
ex.err. FWIW, I don't see any pressing need for B to treat 4) and 2) any
different if B is not going to examine the ex.err for more details anyway,
but I have no problem with abort({"msg",code}) if others really want it.

If I got everything right, I too support this change.

Regards,
Pete
PS for those of you unaware of this, try running the following code:

procedure x()
abort("some possibly quite helpful message")
end procedure
x()

The key point is the ex.err contains "called from line 4", ie it is a run-time
not a compile-time error as things [already] stand.

PPS Actually, there is a weakish argument against abort({"file in use",4}) if
program B decides that 4 means "file not found" or some completely different
error. Worse, it may encourage B to maintain a table of strings which can easily
get wildly out of step.