Better handling of error conditions due to map_setup call#4347
Better handling of error conditions due to map_setup call#4347PaulWessel merged 2 commits intomasterfrom
Conversation
We had a convoluted set of error checks and reporting that gave both correct error messages and confusing wrong references to other things due to a mix of internal and "official" error codes. This PR changes this to a simpler reporting. I was unable to reproduce the SEGV in the OP examples but I believe it was related to bad array indices into the gmt_error_string[] array. This hopefully goes away - if not we will follow up.
anbj
left a comment
There was a problem hiding this comment.
Prints error message and quits, and segv is gone - perfect.
The above command returns error code 71 before this PR, but now it returns 72. Is it expected? |
|
Impressed you noticed! I added one more error code and I added it alphabetically so the numbers did change. Since we do not even publish those values and what they are, does it matter? |
|
A PyGMT test fails due to the change of the error code. It doesn't matter. It's a bad idea to check those non-zero status codes. Will fix it in PyGMT. |
|
I notice the same in a Julia test. Had to fix the error number as I can't break the error message into a non-numeric string. Edit: But shit, I have to remove this test as users that run the tests will have different results depending on their GMT version. |
|
Would you prefer that I move that new error constant to the end of the list instead of having it sorted by name? I think though as long as we are not documenting what these constants are as part of the API then they are basically not defined for users to use. |
|
Better not care about this. I'll have to find a way of not reporting the error number, which doesn't inform much anyway. |
This PR is addressing the issues raised in #4344. We had a convoluted set of error checks and reporting that gave both correct error messages and confusing wrong references to other things due to a mix of internal and "official" error codes. This PR changes this to a simpler reporting. I was unable to reproduce the SEGV in the OP examples but I believe it was related to bad array indices into the gmt_error_string[] array. This hopefully goes away - if not we will follow up.