Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom errors should inherit from StandardError (not Exception) #11

Open
generalmimon opened this issue Feb 12, 2023 · 1 comment
Open
Labels

Comments

@generalmimon
Copy link
Member

See https://www.honeybadger.io/blog/ruby-exception-vs-standarderror-whats-the-difference/#custom-exceptions-should-inherit-from-standarderror:

It means you should always inherit from StandardError, and NEVER from Exception. Inheriting from Exception is bad because it breaks the expected behavior of rescue. People will think they're rescuing all application-level errors but yours will just sail on through.

##
# Common ancestor for all error originating from Kaitai Struct usage.
# Stores KSY source path, pointing to an element supposedly guilty of
# an error.
class KaitaiStructError < Exception

But UnexpectedDataError should be left as is, because it only remains for compatibility with 0.8 and older KS versions (and will be eventually removed):

##
# Unused since Kaitai Struct Compiler v0.9+ - compatibility with
# older versions.
#
# Exception class for an error that occurs when some fixed content
# was expected to appear, but actual data read was different.
class UnexpectedDataError < Exception

@generalmimon
Copy link
Member Author

Yeah, this issue is also reported by RuboCop:

lib/kaitai/struct/struct.rb:692:27: W: [Correctable] Lint/InheritException: Inherit from StandardError instead of Exception.
class KaitaiStructError < Exception
                          ^^^^^^^^^

We should adopt kaitai-io/kaitai_struct_visualizer#38 for runtime library too, and make sure that RuboCop at least doesn't issue any warnings.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant