Obscure error when trying to update ARK with invalid values

[dunn]

I ran into this because my application wasn't doing a good enough job checking the validity of new values of an ARK before trying to update it at CDL. Obviously a hash isn't valid, but I was updating multiple values and the error message didn't identify which of the new values was problematic or why:

irb(main):001:0> ark = Ezid::Identifier.find("ark:/99999/fk4r78kv1g")
I, [2016-03-23T08:33:06.931027 #49199]  INFO -- : EZID GetIdentifierMetadata -- success: ark:/99999/fk4r78kv1g
=> #<Ezid::Identifier id=ark:/99999/fk4r78kv1g>
irb(main):002:0> ark[:target] = { :a => "a", :b => "c" }
=> {:a=>"a", :b=>"c"}
irb(main):003:0> ark.save
ArgumentError: wrong number of arguments (given 2, expected 0..1)
        from /usr/local/lib/ruby/gems/2.3.0/gems/ezid-client-1.4.3/lib/ezid/metadata.rb:57:in `initialize'
        from /usr/local/lib/ruby/gems/2.3.0/gems/hashie-3.4.3/lib/hashie/mash.rb:150:in `new'
        from /usr/local/lib/ruby/gems/2.3.0/gems/hashie-3.4.3/lib/hashie/mash.rb:150:in `dup'
        from /usr/local/lib/ruby/gems/2.3.0/gems/hashie-3.4.3/lib/hashie/mash.rb:276:in `convert_value'
        from /usr/local/lib/ruby/gems/2.3.0/gems/hashie-3.4.3/lib/hashie/mash.rb:175:in `block in deep_update'
        from /usr/local/lib/ruby/gems/2.3.0/gems/hashie-3.4.3/lib/hashie/mash.rb:170:in `each_pair'
        from /usr/local/lib/ruby/gems/2.3.0/gems/hashie-3.4.3/lib/hashie/mash.rb:170:in `deep_update'
        from /usr/local/lib/ruby/gems/2.3.0/gems/ezid-client-1.4.3/lib/ezid/metadata.rb:77:in `update'
        from /usr/local/lib/ruby/gems/2.3.0/gems/ezid-client-1.4.3/lib/ezid/metadata.rb:59:in `initialize'
        from /usr/local/lib/ruby/gems/2.3.0/gems/ezid-client-1.4.3/lib/ezid/requests/identifier_with_metadata_request.rb:13:in `new'
        from /usr/local/lib/ruby/gems/2.3.0/gems/ezid-client-1.4.3/lib/ezid/requests/identifier_with_metadata_request.rb:13:in `initialize'
        from /usr/local/lib/ruby/gems/2.3.0/gems/ezid-client-1.4.3/lib/ezid/requests/request.rb:28:in `new'
        from /usr/local/lib/ruby/gems/2.3.0/gems/ezid-client-1.4.3/lib/ezid/requests/request.rb:28:in `execute'
        from /usr/local/lib/ruby/gems/2.3.0/gems/ezid-client-1.4.3/lib/ezid/client.rb:211:in `execute'
        from /usr/local/lib/ruby/gems/2.3.0/gems/ezid-client-1.4.3/lib/ezid/client.rb:145:in `modify_identifier'
        from /usr/local/lib/ruby/gems/2.3.0/gems/ezid-client-1.4.3/lib/ezid/identifier.rb:314:in `modify'
        from /usr/local/lib/ruby/gems/2.3.0/gems/ezid-client-1.4.3/lib/ezid/identifier.rb:331:in `persist'
        from /usr/local/lib/ruby/gems/2.3.0/gems/ezid-client-1.4.3/lib/ezid/identifier.rb:153:in `save'
        from (irb):3
        from /usr/local/lib/ruby/gems/2.3.0/gems/railties-4.2.5.2/lib/rails/commands/console.rb:110:in `start'
        from /usr/local/lib/ruby/gems/2.3.0/gems/railties-4.2.5.2/lib/rails/commands/console.rb:9:in `start'
        from /usr/local/lib/ruby/gems/2.3.0/gems/railties-4.2.5.2/lib/rails/commands/commands_tasks.rb:68:in `console'
        from /usr/local/lib/ruby/gems/2.3.0/gems/railties-4.2.5.2/lib/rails/commands/commands_tasks.rb:39:in `run_command!'
        from /usr/local/lib/ruby/gems/2.3.0/gems/railties-4.2.5.2/lib/rails/commands.rb:17:in `<top (required)>'
        from bin/rails:8:in `require'
        from bin/rails:8:in `<main>'irb(main):004:0>

So this isn't a bug with ezid-client, just a note that it might help other confused souls if it's possible to catch these user errors earlier.

[dchandekstark]

@dunn I see the problem with the Hash, and there should be a reasonable way to catch that. Are there other conditions?

[dchandekstark]

My inclination is to raise an exception when try to set an enumerable value (responds to :each), since there's no clear way to handle those in any case.

[dunn]

Are there other conditions?

That's the only case I've run up against!

[dunn]

Or do you mean are there further conditions required to reproduce that behavior? None that I'm aware of.

[dchandekstark]

OK, I think raising an exception in the element writer should make it clear enough.

[dchandekstark]

@dunn v1.5.0, just released, addresses the immediate issue.

[dunn]

Oh awesome; thanks so much!