Since I wrote the postfix code, I have found it to be very forgiving and yet solid. You’re free to like any implementation, of course, and, of course, using those implementations you have zero control over anything in them.
Runtime errors are OK if you have robust try-catch (local error handling), which FMP lacks.
If you check the bottom three cases, my logic handles cases where FMP gives the silly unhelpful “?”. A “?” is NOT error handling. That’s just lazy coding at FMI where as I’ve noted in other cases, FMI just dumps the problem in your lap to figure out.
The implementation I coded also handles the in-determinant case 0/0.
Finally, I’ve yet to find a case with supplemental parentheses where the result was not correct. See expression 1 in the screenshot. Of COURSE if you change the parentheses inside the expression, the result would be different.
I have clients using this logic from many apps including one from FMP.
My philosophy is similar to Alan Cooper (father of Visual Basic): don’t report an error, fix the problem in code if possible and still return the correct result (or, worst case, after trying, return a real error message to help the user).
After reading your posting, I just added an “option” to my method to report on unbalanced parens. During the stack push/pop, I just do a simple count++ or count–. If the parens count != 0 at the end (after the last stack pop), I report it with the parens nesting level where the problem happened, but only if the user passes “true” for the new strict argument. Most won’t care or use it, but it’s there now as an option.
Thanks,