According to RubyDoc, SyntaxError is "raised when encountering Ruby code with an invalid syntax."
In my opinion, it should not be raised when attempting to parse JSON. SyntaxError (and other descendants of ScriptError) are typically only raised by the Ruby interpreter. Specifically, SyntaxError doesn't descend from StandardError, making it difficult to catch JSON parsing error while still raising Ruby syntax errors that may occur within the same code block.
I'd encourage you to define a custom Oj::ParseError class that inherits from StandardError. I believe this is what the other JSON libraries do.
I suppose that is better. I'll try to get a new release out in the next day or so.
Cool. No rush.
I can understand using a custom class that inherits from Exception. Why do you feel it is necessary to group parse exceptions with standard errors?
Exception doesn't get caught when you rescue without any arguments, StandardError does, so most people inherit from StandardError when they create custom error classes.
puts "rescued" # this exception won't be caught
puts "rescued" # this will be caught
+1 to a ticket. Oj should define its own exception class derived from StandardError (or even better, RuntimeError)
actually +4, cause my friends are also angry of this issue
I agree that calling rescue without any arguments is a bad practice. I just wanted to show an example.
Perhaps a better example is rescuing from a group of errors by their parent class. For example, in multi_json, I would like to to rescue from all parsing errors, regardless of the parser. If oj raised an Oj::ParseError that inhered from StandardError, I could safely write:
rescue StandardError => exception
raise MultiJson::DecodeError.new(exception.message, exception.backtrace, string)
If I wanted to write this same code today, I'd need to either rescue Exception or manually list all exceptions to rescue, which is difficult to maintain across an ever-changing landscape of JSON parsing libraries. The problem with rescue Exception, is that it would also rescue NoMemoryError, Interrupt, etc. which I explicitly do not want to catch here.
Release 1.4.0 includes the new Exception classes which are raised instead of core exceptions. Please keep the comments and requests coming.