{"record":{"id":"706e7547b97deafb","repo":"ruby-grape/grape","slug":"both-with-option-and-block-cannot-be-passed","errorCode":null,"errorMessage":"both :with option and block cannot be passed","messagePattern":"both :with option and block cannot be passed","errorType":"exception","errorClass":"ArgumentError","httpStatus":null,"severity":"error","filePath":"lib/grape/dsl/request_response.rb","lineNumber":145,"sourceCode":"      #   end\n      #\n      # Note that Grape will automatically go up the class ancestry to\n      # try to find a representing entity, so if you, for example, define\n      # an entity to represent `Object` then all presented objects will\n      # bubble up and utilize the entity provided on that `represent` call.\n      #\n      # @param model_class [Class] The model class that will be represented.\n      # @option options [Class] :with The entity class that will represent the model.\n      def represent(model_class, with:)\n        raise Grape::Exceptions::InvalidWithOptionForRepresent.new unless with.is_a?(Class)\n\n        inheritable_setting.add_representation(model_class, with)\n      end\n\n      private\n\n      def extract_handler(args, with:, block:)\n        raise ArgumentError, 'both :with option and block cannot be passed' if block && with\n\n        return args.pop if args.last.is_a?(Proc)\n        return block if block\n        return unless with\n\n        case with\n        when Proc, Symbol then with\n        when String then with.to_sym\n        else raise ArgumentError, \"with: #{with.class}, expected Symbol, String or Proc\"\n        end\n      end\n    end\n  end\nend\n","sourceCodeStart":127,"sourceCodeEnd":160,"githubUrl":"https://github.com/ruby-grape/grape/blob/22d7975629846a3c0c7bd2b34e140a7a1b4af8f6/lib/grape/dsl/request_response.rb#L127-L160","documentation":"`rescue_from` lets you specify a handler either as an inline block or via the `with:` option (a method name or Proc), but not both - Grape would not know which one wins. `extract_handler` raises 'both :with option and block cannot be passed' when a block is given and `with:` is non-nil.","triggerScenarios":"`rescue_from ArgumentError, with: :render_error do |e| ... end`. `rescue_from :all, with: ->(e) { ... } do |e| ... end` - a do/end block after a with: lambda.","commonSituations":"Refactoring a handler into a named method and forgetting to delete the old block. A stray multiline do/end sneaking in after a `with:` lambda. Merging two rescue_from declarations during conflict resolution.","solutions":["Keep the block and drop `with:`.","Keep `with:` and delete the block, ensuring the named method or lambda is defined on the endpoint."],"exampleFix":"# before\nrescue_from ArgumentError, with: :render_error do |e|\n  error!(e.message, 400)\nend # raises\n\n# after - handler method only\nrescue_from ArgumentError, with: :render_error\ndef render_error(e); error!(e.message, 400); end\n\n# or block only\nrescue_from ArgumentError do |e|\n  error!(e.message, 400)\nend","handlingStrategy":"validation","validationCode":"# House rule: either an inline block XOR with: - never both\nraise ArgumentError, 'pass either block or with:, not both' if handler_block && with_option","typeGuard":null,"tryCatchPattern":null,"preventionTips":["When extracting a handler to a method, delete the block in the same commit.","Avoid single-line `with: ->(e){}` lambdas followed by do/end - easy to create accidentally.","Boot specs per endpoint catch this at load time."],"tags":["grape","rescue-from","handler","argument-conflict"],"backgroundTag":"conflicting-handler-options","analyzedSha":"22d7975629846a3c0c7bd2b34e140a7a1b4af8f6","analyzedAt":"2026-08-21T17:03:54.627Z","schemaVersion":2},"datasetVersion":"2026-08-21T18:17:14.833Z"}