Improve TypeError identification by defining a custom error class

[okumud]

I have suggestions

It is challenging to distinguish whether a TypeError originated from the gem itself.

To enhance the identification of errors originating from the type_struct gem, I propose defining a custom error class for type_struct-specific TypeError.
This would make it easier for users to identify and handle errors specifically related to the gem.

Changes

• Introduce a new custom error class, let's call it TypeConversionError (for example), within your type_struct gem.
  • The TypeConversionError class inherits from standard Ruby TypeError.
• Update the relevant parts of the code to raise instances of TypeConversionError where appropriate.

Benefits

Improved error handling:
Users can easily distinguish between standard Ruby TypeError and TypeConversionError, facilitating more targeted and effective debugging.

Example Usage

require "type_struct/ext"
using TypeStruct::Union::Ext
Baz = TypeStruct.new(
  qux: ArrayOf(Integer | TrueClass | FalseClass) | NilClass
)
begin
  # code that may raise a type error
  Baz.new(qux: 1)
rescue TypeStruct::TypeConversionError => e
  # handle type errors specific to type_struct gem
rescue TypeError => e
  # handle standard Ruby type errors
end

Note

This change does not affect the existing behavior for handling standard Ruby TypeError.

Updated

The example of the error class name TypeStructError is too general.
I have changed it on this issue to TypeConversionError as the example.

[ksss]

Thank you for your valuable suggestion.
However, at this time, I haven't found aspects of this proposal that I can agree with.
I don't find it convenient for that use case.

[okumud]

What I was actually trying to do was error handling in the Rails controller (e.g. responding to invalid parameters by rescue_from TypeStruct::TypeConversionError).
I understand that it doesn't fit the design philosophy.
Thank you for your prompt consideration.

[ksss]

However, I don't have the motivation or resources to handle changes that are not compatible.
Is the main use case for web API?
As an alternative, I recommend using validation in ActiveModel.

[okumud]

@ksss

Thank you for your consideration and response.

However, I don't have the motivation or resources to handle changes that are not compatible.

While I understand the challenges of handling changes that may impact compatibility, I'd like to propose a solution that minimizes such concerns.
By structuring the custom error class to inherit from TypeError, it can keep in compatibility.

TypeConversionError = Class.new(TypeError)

This approach allows for the introduction of the custom error class without compromising the existing usage of TypeError.

Is the main use case for web API?

Yes, it is.
I am developing a RESTful Web API service using Ruby on Rails.
The flexibility provided by TypeStruct is invaluable, especially considering the variations in data formats accepted for different types.

Consequently, having the ability to handle errors consistently in shared components like ApplicationController would greatly enhance the maintainability of the codebase.

e.g.

class ApplicationController
  rescue_from TypeStruct::TypeConversionError do
    # This is not graceful error message, but it is okay for internal purpose APIs.
    render status: :unprocessoble_entity, json: { message: 'invalid_parameter' }
  end
end

[ksss]

That's a great idea. With that approach, Then I think it would be acceptable.
I haven't worked with this library for a long time, so I don't remember my thoughts back then, but when I recently read through the library's code again, I thought,

"How cool is it that TypeStruct throws a TypeError!"

I'm always open to receiving a Pull Request.

[okumud]

Thank you for acceptance of the idea and providing powerful gem.
I re-open this issue, and I would like to make Pull-Request.

[okumud]

@ksss
I'm sorry for the delay in creating the Pull-Request, and it has now been created as #15.
Please take a moment to review the details.

Thank you.