<br><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
I guess that you would prefer to get, for example, an integer or atom as error reason. Correct? </blockquote><div><br></div><div>That's right.</div><div><br></div><div>I like the tuple solution because then I wouldn't have to include the record definition.  Furthermore, I would prefer an atom instead of a macro for the same reason.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
<br>#ssh_msg_disconnect{code = ?SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED,<br>                   description = "Protocol version " ++  StrVsn<br>                                 ++ " not supported",<br>
                   language = "en"},</blockquote><div><br></div><div><br></div><div>This still has some limitations.  What if I'm making a GUI app in Spanish and I wanted to display the unsupported version in a dialog box?  Something like the following would be more flexible...</div>
<div><br></div><div>{error, {ssh_disconnect_protocol_version_not_supported, StrVsn}}</div><div><br></div><div>... and more consistent with the way other parts of OTP work (tcp, ssl).</div><div><br></div><div><br></div><div>
But I'm making a mountain out of a molehill. :)   I really only need to separate auth errors from other kinds of errors.  Any of your ideas would help.</div><div><br></div><div>Dan.</div><div><br></div><div><br></div>
<div><br><div class="gmail_quote">On Thu, May 26, 2011 at 10:09 AM, Niclas Eklund <span dir="ltr"><<a href="mailto:nick@erix.ericsson.se">nick@erix.ericsson.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Hi!<br>
<br>
I guess that you would prefer to get, for example, an integer or atom as error reason. Correct? I.e. so you could match on the case when you get "Unable to connect using the available authentication methods". In this case the generated message is (the macro represents an integer):<br>

<br>
#ssh_msg_disconnect{code = ?SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE,<br>
                    description = "Unable to connect using the available"<br>
                                  " authentication methods",<br>
                    language = "en"},<br>
<br>
But in some cases it contain additional information. E.g.<br>
<br>
#ssh_msg_disconnect{code = ?SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED,<br>
                    description = "Protocol version " ++  StrVsn<br>
                                  ++ " not supported",<br>
                    language = "en"},<br>
<br>
In the latter the description reveals more details. Perhaps the error messages could have been a 3 tuple:<br>
<br>
  {error, Code, Description}<br>
<br>
instead of what's normally used {error, Reason}. Changing the return value would break existing code (applications using SSH), which wouldn't be very popular ;-) Perhaps a configuration parameter could be used to control this (the default behaviour should as it is) ....<br>

<br>
Best Regards,<br>
<br>
Niclas @ Erlang/OTP<div><div></div><div class="h5"><br>
<br>
On Tue, 10 May 2011, Daniel Goertzen wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am using ssh to automatically connect and operate a remote device.  I'd<br>
like to distinguish authentication failures from other kinds of failures.<br>
Currently I will get this as an auth failure from ssh:connect():<br>
<br>
{error,"Unable to connect using the available authentication methods"}<br>
<br>
Now I could include that error string in a pattern to detect an auth<br>
failure, but it feels rather brittle (ie, what if someone changes the<br>
wording).  Is there a better way to do it?  Is this an API design bug?<br>
<br>
Regards,<br>
Dan.<br>
<br>
</blockquote>
<br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Daniel Goertzen<br>-----------------<br><a href="mailto:dang@networkintegritysystems.com">dang@networkintegritysystems.com</a> (work)<br><a href="mailto:daniel.goertzen@gmail.com">daniel.goertzen@gmail.com</a> (home)<br>
-----------------<br>1 204 272 6149 (home/office)<br>1 204 470 8360 (mobile)<br>-----------------<br><br><br><br>
</div>