Try/Catch works on Mac & Linux but not Windows

General
1

This is a problem I’m having with Xojo 2016r3 and Windows 7. So, if it is a Xojo bug, then it may not be present in current versions.

I have a project that uses Bob Delaney’s big float plug-in to do some extended precision calculations. This plug-in doesn’t return NaN’s when there is a calculation error such as divide by zero. Instead it raises an exception. I have the calculations enclosed in a try/catch block. When I deliberately do a divide by zero to test the exception handling, this block correctly handles it on both Mac and Linux platforms. But on Windows, it’s not caught and was forcing the application to shut down, until I added an application.unhandledexception event handler. This is a clumsy way to have to handle these exceptions. I’m not an expert on exception handling. So, I may be missing something simple.

The code is fairly simple and looks like this:

  try
     doBigfloatCalculation
  catch err as fpDivideByZeroException
     myErrorCodeStuff
  catch err
     myErrorCodeStuff
  end try

When it was causing the Windows version to quit, the error message that it gave was indeed fpDivideByZeroException unhandled exception.

Has anyone else run into this problem?

2

A log shot, did you try replacing the second catch err by catch err2 ?

3

I’ve never tried a Try statement with typed Catch and an untyped Catch but I’m guessing that may be the issue. Perhaps you should refactor it to a single Catch statement like

try
     doBigfloatCalculation
catch err 
     If err IsA fpDivideByZeroException then     
        myErrorCodeStuff
     Else
        myErrorCodeStuff
     End If  
end try

and see if that works for you.

4

Initially I used only a single untyped catch section. Then, reading through some posts on the forum, I saw a comment that suggested that a typed catch might be more reliable. So, I changed the single catch block to a single typed catch block. That didn’t work either. So, I then added the second untyped catch block. I’ll try changing the name of the second error variable, but based on what I’ve already done, I doubt that it will make any differerence.

After my first post, I decided to drill down inside the “doBigfloatCalculation” routine and wrap the actual divide operation in a try/catch block. That didn’t catch it either. Also, in the button action event handler code that calls the code from the first post, I wrapped that code in a try/catch block. None of them worked in the Windows version, but all worked in Mac & Linux. I should also mention that I checked to make sure that the code doesn’t have any #pragma directives that would affect exception handling or any other Windows specific directives.

5

Hi Robert,

Maybe this isn’t helpful, but putting the exception issue aside for a moment.

When it comes to divide-by-zero challenges, this is what I might do in Xojo.

// following is pseudo-code only
If couldBeZero = CType(0, Double) Then
   // assign zero rather than NaN to allow calculation to continue
   product = CType(0, Double) 
Else
   product = operand / couldBeZero
End If

I do a ton of costing algorithm programming in SQL Server. So whenever I have a numeric variable that may be used as a factor in a division calculation - and if that factor value could be zero; instead of raising an exception or a transaction-rollback, I simply check if the factor is zero before the division, and if so, I assign the results of the division to zero and bypass the divide-by-zero error so the algorithm can continue.

This technique has proven quite reliable for me, as the algorithms that I build are spec’d and designed by accountants, and they double-check all my work.

I hope this helps in some way.

6

Thanks Scott. I’d considered something like that, but it would involve a huge number of code changes. It wouldn’t be too bad for math functions, because I could just create my own version of them. For example, I could make a mySqrt() function that checks for a negative argument, but in the case of operators like division, I would have to disassemble a huge number of math expressions to check if the divisor is zero.

1 Like
7

Hello Robert.

Slightly off topic, but have you heard from Bob Delaney of late? Is he still maintaining his plugins?

8

There was a comment in a recent thread that he isn’t planning to support Apple Silicon.

That’s the most recent thing that I’ve seen. If he decides to stop supporting it, I hope he’ll open source it. He’s already posted the source code for his math routines, but I don’t think the actual plug-in source code has been posted.

9

Update:
Since Xojo products are on sale this week, I decided it was finally time to get a new license. So, I’ve now built the app with 2021r1.1.

The bad news is that it doesn’t fix the problem in the Windows version. The good news is that I was able to find a reasonably easy workaround using Scott Cadillac’s suggestion to pre-screen the operands. I used some conditional compilation so that this is only applied to the Windows version. Therefore, it won’t slow down the Mac or Linux versions. Windows users will have to take what they can get. :slight_smile:

Of course, I’d still like to find out why this is happening. Is it possible that there is a bug in the Windows version of the plug-in? I don’t know enough about how plug-ins work to know whether it could generate an exception that can’t be trapped.

1 Like
10

If it’s something you can easily reproduce, file a bug report so we can look at it.

11

And I’d like to know where the exception (the one you can’t catch properly on Windows) is occurring.
Is it the main document window, a modal dialog window? Or is this about a console application, a Thread, …?

At least with 2016r3 it used to be that Exceptions on modal dialogs were broken on TargetWindows. It wouldn’t be a big surprise if that particular case hasn’t been fixed until 2021r1. I may be wrong about that one, but can’t look up the Feedback case while being on holidays without a computer.

At least I think the ‘where it is happening’ might be an important piece of information when trying to find the cause of this issue.

12

Now that I know that the problem still exists in 2021r1.1, I’ll definitely do that.
It’s a fairly big app. I’ll try to make a simpler version and see if I can duplicate the bug.

It’s a desktop app and the problem occurs in the main window. No threads. The user clicks a button that runs the routine. The only thing out of the ordinary is that, within the main routine, there are several routines that are called using method.invoke. One of the methods called that way has the bigfloat divide that’s creating the divide by zero exception. I’ve tried including a try/catch in that innermost method, but it didn’t make any difference.

13

I filed a feedback case: 64645

1 Like
14

In addition to filing a feedback case, I got in touch with Bob Delaney a couple of days ago. He’s now updated the fpPlugin to version 11.0, and it now supports Apple silicon. It doesn’t seem to have solved my try/catch problem, but I’m glad to see that there’s now Apple silicon support.

1 Like