Closed samhatchett closed 5 years ago
@samhatchett Like you say, we can ...
Or ...
Another thought ...
I think my leaning is to not throw exceptions for non-exceptional behavior. Exceptions (at least in the C-like world) are for crazy things that should not happen but might on occasion mess something up.
In the JavaScript world, this would be a situation for passing an error callback to the function in question - which is very javascripty.
I'm not so clear on what is pythonic - but it looks like exceptions are pretty ubiquitous since you can also do crazy (i.e. "pythonic") things like:
When an exception occurs, it may have an associated value, also known as the exception’s argument. The presence and type of the argument depend on the exception type.
... which may be the way to go
Looks like they already thought of this ... https://docs.python.org/3/library/warnings.html
@samhatchett this turned out to be fairly straight forward. Since err_check()
was already returning the error code it was available to the wrapper. All I needed to do was modify the custom exception logic in toolkit.i
. I wrote some tests and we should be in business.
Wow that’s incredible. Thanks Michael!
Updated wheels can be found here:
https://ci.appveyor.com/project/michaeltryby/epanet-python/branch/dev/artifacts
when iterating through a hydraulic simulation using the
nextH
-type methods, if there is an epanet-related error like "negative pressures", the stepping call will raise an exception. We can catch it, but we will not get thetime
return value from the function (which we need for various reasons).I see that the
toolkit.i
file declares some macros to accomplish both routing of OUTVALUEs to returns, and checking the C toolkit return value to raise, but this is preventing us from using the functions as we desire.our workaround seems to be changing the swig interface file to avoid raising, or to avoid passing the OUTVALUE as a return so we can retrieve it even if the function raises.
any thoughts?