Closed ktras closed 5 months ago
@bonachea Thanks for the suggested changes. After making them, the function set_stat_errmsg_or_abort
is never called. Is this a function we think will likely be useful in the future? Or should we delete the function? @rouson, @everythingfunctional, any thoughts?
I would have changed set_stat_errmsg_or_abort
to call gasnett_fatalerror
instead of hard-coding that multiple places.
I would have changed
set_stat_errmsg_or_abort
to callgasnett_fatalerror
instead of hard-coding that multiple places.
@everythingfunctional what you suggest is essentially the "before" code. The "after" code I suggested with a direct call will generate a more useful error message.
@bonachea Thanks for the suggested changes. After making them, the function
set_stat_errmsg_or_abort
is never called. Is this a function we think will likely be useful in the future? Or should we delete the function? @rouson, @everythingfunctional, any thoughts?
@ktras I'm in favor of removing the dead code. I don't expect we'll be supporting any non-fatal errors anytime soon other than allocation failure, and that doesn't use this code path.
Ok, but then we should adjust the interface to set_stat_errmsg_or_abort
to allow for passing the information/message we want, rather than getting rid of it. At some point we will want the logic it describes, and will be easier to make the change in one place instead of multiple.
That said, if you think
I don't expect we'll be supporting any non-fatal errors anytime soon other than allocation failure, and that doesn't use this code path.
I'm fine with just delaying that refactoring for now.
Closes #81.