Improve TypeError identification by defining a custom error class

[okumud]

I have suggestions

The current behavior of the type_struct gem returns a standard Ruby TypeError class. However, when catching TypeError in frameworks like Ruby on Rails, it can be challenging to determine whether it originated from the type_struct gem.

• resolves Improve TypeError identification by defining a custom error class #14

How

This pull request proposes the following changes:

Define a new custom error class, TypeStruct::TypeError, inherited from TypeError.

Benefits

Improved error identification: Users can easily distinguish between standard Ruby TypeError and TypeStruct::TypeError, facilitating more targeted debugging.
Seamless integration: The introduction of the custom error class doesn't disrupt the existing usage of standard Ruby TypeError.

Examples

# app/controllers/application_controller.rb

class ApplicationController < ActionController::Base
  # ...

  # Example of using rescue_from with TypeStruct::TypeError
  rescue_from TypeStruct::TypeError do |e|
    # Customize the error response as needed
    render status: :unprocessable_entity,
           json: { error: 'TypeStruct error', message: e.message }
  end

  # ...
end

These changes enhance error handling in a Ruby on Rails context by allowing for more precise identification of errors originating from the type_struct gem.

[ksss]

@okumud Thank you for your suggestion.

I apologize, but could you please clarify again?
In what situations would the following code pose a problem?

class ApplicationController < ActionController::Base
  rescue_from TypeError do |e|
    render status: :unprocessable_entity,
           json: { error: 'TypeStruct error', message: e.message }
  end
end

It's clear that the operation should be interrupted due to an error, and the source of the TypeError can be determined from the backtrace.
The content of the error can also be included in the message.
For API purposes, it is expected to use TypeStruct::ClassMethods#from_hash, but #from_hash may also raise a TypeStruct::MultiTypeError.

I would like to know in what cases this could become a problem.

[okumud]

@ksss

Thank you for review.

I want to identify the TypeError from the gem or it comes from another code.

1.Following should be unhandled error as a bug: HTTP 500

1 + 'string' #  => may get TypeError, this is bug.

2.Following should be invalid parameter: HTTP 422

TitleParser = TypeStruct.new(title: String)
ContentParser = TypeStruct.new(content: TitleParser)
request_hash = JSON.parse(request.body.read)
# => {content: [{title: 'hoge'}]} # `content` is should be an object, but an array
# OR 
# => []
ContentParser.from_hash(request_hash) # raise TypeError

[ksss]

For example, I seem to want a 500 error when a value of the wrong type is assigned to one attribute, but this modification would be caught by rescue_from TypeStruct::TypeError?

TitleParser = TypeStruct.new(title: String)
t = TitleParser.new
t.title = 123 #=> should it raise TypeError or TypeStruct::TypeError ?

Can't we fix the problem by modifying just this line to MultiTypeError?

https://github.com/ksss/type_struct/blob/0a3810ac01c362cebfd4aa45d8aaf8458b169c55/lib/type_struct.rb#L13C38-L13C38

[okumud]

I'm sorry for the delayed response.
Your suggestion is good to me.
It can be far from this Pull-Request, so I would re-create the Pull-Request (#16).

Therefore, I close this Pull-Request.
Thank you.