next »

[Tim B.]

We have made extensive use of this in our project, but the side effect is that error messages are not suppressed and still go to the log.  We could redirect these in every statement with STARTLOG, but it's not really ideal. 

Is there any other way of doing it, or could something like a profile directive be added in the future?

[Reuben B.]

To avoid messages going to the ERRORLOG, use WHENEVER ANY ERROR CONTINUE https://4js.com/online_documentation/fjs-fgl-manual-html/User/Exceptions.html#TRACE, unfortunately that doesn't help you as TRY is effectively a WHENEVER ANY ERROR GOTO https://4js.com/online_documentation/fjs-fgl-manual-html/User/Exceptions.html#TRYCATCH

I'm guessing you are using TRY so that ...

Code

   TRY
      LET x =  1/0
   CATCH
      CASE STATUS
         WHEN -1202 DISPLAY "Divide by zero error"
         OTHERWISE CALL ERRORLOG("Some other error")
      END CASE
   END TRY

... is the equivalent of ...

Code

   WHENEVER ANY ERROR CONTINUE
   LET x =  1/0
   CASE STATUS
      WHEN -1202 DISPLAY "Divide by zero error"
      OTHERWISE CALL ERRORLOG("Some other error")
   END CASE
   WHENEVER ANY ERROR STOP

... and as you've discovered, the TRY will write messages to the ERRORLOG whilst WHENEVER ANY ERROR CONTINUE doesn't.

Personally I'd like to see CATCH be able to trap certain exceptions ...

Code

WHENEVER ANY ERROR CALL error_handler
TRY
   LET x = 1/0
CATCH -1202
   DISPLAY "Divide by zero error"
END TRY

... so that I can handle the error I have anticipated, and let the normal error handler deal with unexpected errors.  Certainly in that case I wouldn't want the error I have anticipated and dealt with to appear in the errorlog, but I would want the unanticipated error to be in the errorlog.

For now, you could get clever with the pre-processor and do something like ...

Code

&define TRY_NOLOG CALL STARTLOG("/dev/null") TRY
&define END_TRY_NOLOG END TRY CALL STARTLOG("error.log")
 
  TRY_NOLOG
     LET x =  1/0
  CATCH
     CASE STATUS
        WHEN -1202 DISPLAY "Divide by zero error"
     END CASE
  END_TRY_NOLOG

Reuben

[Sebastien F.]

Hello,

I would avoid to use the preprocessor until there is no other way to solve a blocking problem or missing language instruction.

So I would not use preprocessor macros for this issue, having additional records in the log is not that critical.
You get the line number in the source so you know if comes from a TRY/CATCH block and can be ignored.
But I agree it can be annoying.

I will talk with the team to see what we can do.

Seb

[Tim B.]

Thanks for the responses.   The errors in the log are not critical, but we keep a close eye on them, and there are now so many errors it's difficult to find the real ones amongst all the rest.

We're using TRY for a number of different things, but mostly to check that DELETEs are either successful, or fail due to referencial integrity issues (which saves a lot of checking).

Being able to catch specific exceptions which you are expecting (and avoid the error logging) would be a very good enhancement.

[Tim B.]

Has there been an further thoughts on this one al all?

[Sebastien F.]

Hello,
The topic is registered in our bug database with id #20606
Seb