DialogCancelError - class or interface?

[thinkOfaNumber]

I'm submitting a feature request

• Library Version:
  aurelia-dialog 1.0.0-rc.1.0.3

(I think the other bug template questions don't apply to a feature request but I can provide if required)

I'm using aurelia-dialog to confirm an action that gets posted to the server to change some object. It seems using rejectOnCancel is a good way to skip over the promise chain that deals with successfully changing the object. In the catch handler I need to differentiate between the respective DialogCancelError or some other error (e.g. from the httpClient).

Because DialogCancelError is an interface and not a class, I can't use the simple pattern to detect the type of error:

catch(error => {
    if (error instanceof DialogCancelError) {
        // handle the dialog cancel action
    } else {
        // handle a http method error
    }
}

Instead I have to use some sort of duck-typing.

My feature request (and I could create a PR if someone likes the idea) is to use a class instead so that I can use the pattern above.

If there's a better way of doing this, please let me know! I would rather not set rejectOnCancel: false because it's a very neat way of skipping the rest of the promise chain which would otherwise require passing and checking this cancel state through each then() method:

someMethod() {
    this.dialogService.open({
        viewModel: ...,
        model: ...,
        rejectOnCancel: true
    }).whenClosed(response => {
        this.busy = true;
        return this.service.someServerMethod(...);
    }).then(() => {
        // do stuff if the server method is successful, such as notifications, updates, etc.
        // there may be multiple then() handlers chained up here
    }).catch(error => {
        if (error instanceof DialogCancelError) {
            // handle the dialog cancel action
        } else {
            // handle a http method error
        }
    }).then(() => {
        this.busy = false;
    });
}

[StrahilKazlachev]

The reason we used an interface are the Error subclassing issues when targeting <ES2015.
I prefer not introducing them. Also I don't find duck-typing that uncommon.
@PWKad Any comment from you?

[thinkOfaNumber]

Ohhhh... that!

[Alexander-Taran]

@thinkOfaNumber do you think it can be closed?

[thinkOfaNumber]

It would be nice to move away from duck-typing, but I have no idea how error subclassing issues would affect other users of the framework! Given this is just my opinion and it's been "noted", then yes, I'll close 👍

[StrahilKazlachev]

For me this issue is complementary to #328.

[Navyashreess]

from the dialog service I am opening the popup , but on close we have to open some validation popup . how to do that on close action from dialog service