Best practice for error answer?

[SunFulong]

When call a procedure, such as user authentication, if password invalid, should the callee answer an ERROR message, or an YIELD message to the dealer?

[ecorm]

I think questions such as this are better asked under the Discussions area for this repo: https://github.com/wamp-proto/wamp-proto/discussions

[SunFulong]

OK, I will post here after.

[oberstet]

When call a procedure, such as user authentication

not sure I fully understand what you refer to:

a) Client connects and performs WAMP authentication OR
b) you have configured dynamic WAMP authentication in your Router - and the configured router side WAMP procedure being called to authenticate incoming clients (that is a different authentication exchange) needs to be authenticated itself

In case you meant a):

When a client supplies wrong credentials during WAMP authentication, such as a wrong password, Crossbar will send [ABORT, Details|dict, Reason|uri] with Reason == "wamp.error.not_authorized".

WAMP authentication is happening as part of the initial WAMP opening handshake, which are all WAMP messages before WELCOME.

https://wamp-proto.org/wamp_latest_ietf.html#name-session-establishment

At that point, the router may only either send WELCOME or ABORT, not ERROR.

If it sends WELCOME, the router has accepted the client and assigns a session ID. Thus, the authentication must have been successful, and hence, neither ERROR nor YIELD is involved.

[SunFulong]

Sorry, not the protocol level authenticate, I mean, in my own application, user want to login in the site, called a procedure named "net.example.login", but provide wrong credentials, should the procedure answer a YIELD message contains "incorrect credentials", or answer an ERROR message with uri "net.example.login.error"?

[KSDaemon]

Em... I think this is really up to you as a developer to choose the way.
How does site login RPC differs from idk get the shopping cart one? IDK.

I think this question is the same as the one asked in the context of HTTP REST API: what HTTP status codes should be returned for different operations and cases? Someone prefers to always return 200/OK and then in the body has something like error: true, others return 403/Forbidden and error description in the body. But you can find a plenty examples of both around :)

Here is the same situation. Just choose one approach, describe it in dev docs, and follow it.

[SunFulong]

Yes, the spec said:

If the Callee is unable to process or finish the execution of the call, or the application code implementing the procedure raises an exception or otherwise runs into an error, the Callee sends an ERROR message to the Dealer

I think, for every procedure, should have static/fixed in and out params, ERROR is a good options here, but as you say, 200/OK then success: false.

So I asked here, do we have a best practice for it?

[KSDaemon]

I can only state my opinion here: If somewhere error happens — it is an error and should be processed as an error (if the underlying tech provides such semantics).

• HTTP REST has 40* codes for errors.
• WAMP has ERROR messages.

[KSDaemon]

Moreover: you can throw a custom error with business understandable message code and other info

[oberstet]

Whether you consider something at the application level as "an error" is up to the application designer / developer in general, I agree with @KSDaemon

If you want to signal "an error", then again you have the option to: encode it into regular RESULT or encode it into ERROR.

The advantage of the latter could be, when the client library used can auto-map ERROR to the native language error mechanism. E.g. AutobahnPython will raise a Python exception into user code upon ERROR.

If you disagree with such error mechanisms - like exceptions - in general, you might of course do so, and use normal RESULT. Some languages follow this approach from the language design, e.g. Rust by using a union type like Result<T, E>

https://doc.rust-lang.org/book/ch09-00-error-handling.html
https://doc.rust-lang.org/std/option/

[SunFulong]

I agree with using ERROR message too, just to check with the spec authors if this is the recommended way.