From: "kenn (Kenn Ejima)" <redmine@...>
Date: 2012-11-17T09:05:47+09:00
Subject: [ruby-core:49465] [ruby-trunk - Feature #7376][Open] Proposal for new syntax construct to define errors


Issue #7376 has been reported by kenn (Kenn Ejima).

----------------------------------------
Feature #7376: Proposal for new syntax construct to define errors
https://bugs.ruby-lang.org/issues/7376

Author: kenn (Kenn Ejima)
Status: Open
Priority: Normal
Assignee: 
Category: 
Target version: 


=begin
As discussed here - https://gist.github.com/4091803

When we define an error class in a module, we do one of the following two ways.

  module App
    class Error < StandardError; end
    class ServerError < Error; end
    class ClientError < Error; end
  end

  module App
    Error = Class.new(StandardError)
    ServerError = Class.new(Error)
    ClientError = Class.new(Error)
  end

IMO, the ugliness of the syntax is partly responsible that not many libraries have custom errors of their own, even when it makes sense.

It would be great if we could write this way instead:

  module App
    define_error Error                            # inherits StandardError by default
    define_error ServerError, ClientError < Error # inherits App::Error
  end

Which would encourage define errors.

I realized that the same could apply to empty class inheritance in general, but errors are much more likely to inherit without adding any features - thus naming specifically (({define_error})) here.

Or, as Matz suggested in the comment:

  module App
    define_error :Error
    define_error :ServerError, :ClientError, super: Error
  end

this one looks good too.
=end



-- 
http://bugs.ruby-lang.org/