Skip to content

register python exceptions and update exceptions handling#3169

Merged
askhade merged 1 commit intoonnx:masterfrom
askhade:exception_handling_part1
Jan 19, 2021
Merged

register python exceptions and update exceptions handling#3169
askhade merged 1 commit intoonnx:masterfrom
askhade:exception_handling_part1

Conversation

@askhade
Copy link
Copy Markdown
Contributor

@askhade askhade commented Dec 15, 2020

Signed-off-by: Ashwini Khade askhade@microsoft.com

@askhade askhade requested review from a team as code owners December 15, 2020 19:50
Copy link
Copy Markdown
Member

@jcwchen jcwchen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Others LGTM. Thank you so much for organizing exceptions.

Comment thread onnx/shape_inference/implementation.cc
Comment thread onnx/cpp2py_export.cc
// Submodule `shape_inference`
auto shape_inference = onnx_cpp2py_export.def_submodule("shape_inference");
shape_inference.doc() = "Shape Inference submodule";
py::register_exception<InferenceError>(shape_inference, "InferenceError");
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this intended to cover both shape-inference errors as well as type-errors? Wondering why module is called "shape inference", while the exception is plain "InferenceError".

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes both module and exception class are intended to handle both type and shape inference.... I am simply registering the exception here...

Comment thread onnx/shape_inference/implementation.cc
Comment thread onnx/cpp2py_export.cc
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if making strict_mode into an integer (called mode, restricted to values 0 and 1 currently) will give us more flexibility in the future. For example, may be we could treat it as a compatibility_mode indicator indicating that we desire the behavior in version 1.7 or 1.8, etc. In the future, we could potentially end up with more than 2 modes from a compatibility-mode perspective.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am leaning towards still keeping the strict_mode as true\false in python and change the one in c++ interface to int... when we add more granularity we can still keep the python api for backward compatibility and add a new api in python for the new approach

@askhade askhade force-pushed the exception_handling_part1 branch 2 times, most recently from 0268ade to 9bb3b88 Compare January 19, 2021 18:55
Signed-off-by: Ashwini Khade <askhade@microsoft.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants