2
100%
master: 100%

Ran 12 Nov 2019 08:56PM UTC

Files 1

Run time 0s

Badge

Embed ▾

Committed 12 Nov 2019 08:56PM UTC coverage: 100.0%. Remained the same

Job # 2.3.8, GRAPHQL_RUBY_VERSION=1_8, graphql-1.8.gemfile

Build Type

push

travis-ci

Committed by

exAspArk

Commit Message

Feature: handle rescue_from Module arguments properly (#19)

There is a common pattern for `rescue_from` and alike methods usage, to
pass as an argument a module which handles similar exceptions
processing. The most useful case (and the reason why I proposed that
change) is to handle different network errors with only on class.

In our project it's called Handle::NetworkErrors, it's a module which
aggregates handling of more then 20 different errors whose meaning is
just "something was wrong with the network" and in 99% of the cases it's
reasonable to handle them in exact similar way.

Unfortunately, without proposed change it's impossible to pass to
graphql-errors `rescue_from` a module. It has to be a class...
The other implementations of same method in Rails and Sidekiq accepts
Module as well as a Class.

So, my point is that would be great to have `rescue_from` behavior in a
cannonical way (or you may call it, principle of least surprise).

Run Details

40 of 40 relevant lines covered (100.0%)

71.18 hits per line

exAspArk / graphql-errors / 56 / 2
100%
master: 100%

README BADGES
x

Markdown

Textile

RDoc

HTML

Rst

Source Files on job 56.2 (2.3.8, GRAPHQL_RUBY_VERSION=1_8, graphql-1.8.gemfile)

exAspArk / graphql-errors / 56 / 2 100% master: 100%

README BADGES x

Markdown

Textile

RDoc

HTML

Rst

Source Files on job 56.2 (2.3.8, GRAPHQL_RUBY_VERSION=1_8, graphql-1.8.gemfile)

exAspArk / graphql-errors / 56 / 2
100%
master: 100%

README BADGES
x