Dear all,
I developed an application that perform some calculations. This application has a gui version and a console version, it runs on windows and linux.
Both apps use the same units for calculation, only the interface units are different.
I have some problems in the exception handling.
Some calculations include ln operations.
The calculations are under try except.

Sometimes happens that the argument (a) of b:= ln(a) is negative. The gui app handles this operation giving as result b = NaN or Inf and it does not raise any exception while the concole app raise an exception: External SIGFPE.

How can I obtain the same behaviour on my app both on GUI and console? Which options I have to check?

Regards,
Andrea

The calculations are under try except.

For what reason?

An exception down in some calculation doesn't give you any clue of what exactly went wrong, only that *something* went wrong.

Sometimes happens that the argument (a) of b:= ln(a) is negative.

I'd check this just before the operation, then you won't get an can wrap that in a MyLn function, if you need ln() more often.

DoDi

Il 09/03/2011 12:49, Hans-Peter Diettrich ha scritto:

I'd check this just before the operation, then you won't get an can wrap that in a MyLn function, if you need ln() more often.

ok. I know. but my question is more general and it is:

The gui app handles this operation giving as result b = NaN or Inf and it does not raise any exception while the concole app raise an exception: External SIGFPE.

How can I obtain the same behaviour on my app both on GUI and console? Which options I have to check?

Some LCL widgetsets use this:

  {$if defined(cpui386) or defined(cpux86_64)}
    {$IFDEF windows}
      Set8087CW($133F);
    {$ELSE}
      SetExceptionMask(GetExceptionMask + [exZeroDivide,exInvalidOp]);
    {$ENDIF}
  {$ifend}

Mattias

Il 09/03/2011 17:29, Mattias Gaertner ha scritto:

thanks!

2011/3/9 Hans-Peter Diettrich :

An exception down in some calculation doesn't give you any clue of what exactly went wrong, only that *something* went wrong.

It can often be useful and remove a lot of if/else for cleanly exiting a bunch of nested loops and functions (and also save clock cycles and make the code much more compact and clearer) if you let it *automatically* unwind the the call stack (instead of writing code for this) whenever the exception occurs (of course only if you really know why your exceptions would occur).

Many people recommend not using exceptions as control structures but IMHO exceptions *are* control structures and can (and should) be used as such (if appropriate). In some other languages (Python for example) this is even considered good programming style and recommended because it can make certain code much cleaner and easier to understand.

IMO exception handling (SEH) serves two strictly different purposes: try-finally allows to protect resources and clean up, while try-except allows to modify the control flow.

My comment was about proceeding after an exception occured, i.e. where to place the try-except block, and what to do within that exception handler. When a whole operation should be aborted on an invalid argument, raising an exception will be fine, and catching it in some higher level in the call stack (or in the default application handler). Otherwise, when the error can be detected and/or handled in the same place, throwing an exception can be evitable overhead.

DoDi

That's usually when exceptions are raised explicitely. Either by you or by some deeper library part. Not during calculation.

Many people recommend not using exceptions as control structures but IMHO exceptions *are* control structures and can (and should) be used as such (if appropriate).

A big if... And it depends on the application. Specially applications that have abortable transactions (web and db) this is useful, since one exception and a few try finallys can safely abort the current transaction, and return to a known good state. (waiting for next request)

In many other applications, the program is essentially in an undefined state, and continuing is risky or useless.

In some other languages (Python for example) this is even considered good programming style and recommended because it can make certain code much cleaner and easier to understand.

Python also considers block-by-ident good practice :-)