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

add InvalidSuriSyntaxError, MoabRuntimeError, MoabStandardError #160

Merged
merged 2 commits into from Nov 15, 2019

Conversation

ndushay
Copy link
Member

@ndushay ndushay commented Nov 15, 2019

Why was this change made?

Closes #159

To fix a kludge in preservation_catalog (see https://github.com/sul-dlss/preservation_catalog/pull/1207/files) that would become more onerous as prescat gets more API functionality to replace sdr-services-app.

Was the usage documentation (e.g. wiki, README) updated?

N/A

@coveralls
Copy link

coveralls commented Nov 15, 2019

Coverage Status

Coverage increased (+0.0007%) to 98.223% when pulling c17df9c on exception-ize into f311ab9 on master.

Copy link
Member

@mjgiarlo mjgiarlo left a comment

Choose a reason for hiding this comment

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

Two fairly small questions: one about style and one about error classes.

@@ -259,7 +259,7 @@ def create_tarfile(tar_pathname = nil)
rescue
shell_execute(tar_cmd.sub('--force-local', ''))
end
raise "Unable to create tarfile #{tar_pathname}" unless tar_pathname.exist?
raise(MoabRuntimeError, "Unable to create tarfile #{tar_pathname}") unless tar_pathname.exist?
Copy link
Member

Choose a reason for hiding this comment

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

This one is trivial: why the parens? I don't think we need them, and it'd look a tad bit more idiomatic to my eyes without them (like before). Totally a style preference, so this isn't blocking; I'm just curious why you added parens to each of these.

Copy link
Member Author

Choose a reason for hiding this comment

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

I believed it was easier to read with parens when followed by unless or if. Perhaps I overdid it.

@@ -1,13 +1,9 @@
module Moab
class ObjectNotFoundException < RuntimeError
end
class MoabRuntimeError < RuntimeError; end
Copy link
Member

Choose a reason for hiding this comment

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

I wonder whether you're open to declaring a single MoabError class rather than two classes. Or maybe there is some value to distinguishing between a Moab "standard" error and a Moab "runtime" error? That was there is a single class for all custom errors in this codebase.

Copy link
Member Author

@ndushay ndushay Nov 15, 2019

Choose a reason for hiding this comment

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

The value is that one of the exceptions that used to be thrown is StandardError, so it seemed useful to do it this way. My goal is to do a minor release of MoabVersioning so there is absolutely no ill effect to any app using the gem -- I don't want to cause work for any consumers except pres_cat, where John and Peter did a kludge because they couldn't do this PR at the time. (See sul-dlss/preservation_catalog#1229 (comment), see also https://github.com/sul-dlss/preservation_catalog/pull/1207/files)

Copy link
Member

Choose a reason for hiding this comment

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

@ndushay Hmm, I'm not sure I follow. Are you saying that the value of making subclasses of StandardError and RuntimeError is that downstream code can rescue the RuntimeError children without accidentally rescuing the StandardError children?

Copy link
Member Author

Choose a reason for hiding this comment

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

yup - just in case.

class InvalidMetadataException < RuntimeError
end

class ValidationException < RuntimeError
Copy link
Member Author

Choose a reason for hiding this comment

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

ValidationException is not used.

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.

'Identifier has invalid suri syntax' error should have its own class
5 participants