Reject with an error object about request-promise HOT 11 CLOSED

Hi @jakecraige its a valid point. However, I would prefer not to break the backwards-compatibility so I would introduce a new option flag with which you could turn this different rejection on.

Thinking outside the box maybe adding a .toString() to the rejection object would also work?

from request-promise.

@analog-nico I'm sorry but rejecting with an Error Object is the standard way to do.

from request-promise.

We can extend the error object in the reject. That said, what practical usecases are you being blocked for?  

—
Ty

On Wed, Feb 4, 2015 at 2:27 PM, Nicolai Kamenzky [email protected]
wrote:

Hi @jakecraige its a valid point. However, I would prefer not to break the backwards-compatibility so I would introduce a new option flag with which you could turn this different rejection on.

Thinking outside the box maybe adding a .toString() to the rejection object would also work?

Reply to this email directly or view it on GitHub:
#38 (comment)

from request-promise.

@JSteunou I am completely with you. However, IMO we also need to consider the existing users who overlook a breaking chance notice when updating. We would actually mess with their error recovery code... Anyway, we should look forward as @tyabonil says.

I would say the following code would not break backward-compatibility since the Error objects have the same properties as the objects in the current implementation:

    if (err) {

        self._rp_reject(_.assign(new RequestError(String(err)), {
            error: err,
            options: self._rp_options,
            response: response
        }));

    } else if (self._rp_options.simple && !(/^2/.test('' + response.statusCode))) {

        self._rp_reject(_.assign(new StatusCodeError(response.statusCode + ' - ' + body), {
            error: body,
            options: self._rp_options,
            response: response,
            statusCode: response.statusCode
        }));

    }

Would that cover your use cases?

from request-promise.

semver can prevent breaking changes updates.

from request-promise.

@JSteunou Being realistic people may still overlook breaking changes. And those who don't should not need to migrate a whole lot. I hope my proposed solution can meet all interests. Does it meet yours?

from request-promise.

@jakecraige Does my proposed solution meet your needs? In the first case Mocha would display the stack trace starting from the code in Request-Promise not the one of the err returned by Request. I hope that is fine.

from request-promise.

@analog-nico That solution sounds good to me. It would fix the issue I'm seeing and maintain backwards compat 👍

from request-promise.

I just published version 0.4.0 to npm.

from request-promise.

Looks great. Thanks for taking care of this @analog-nico !

from request-promise.

You are welcome. If anything comes up feel free to ping me on Gitter or open another issue.

from request-promise.