Adding error enum to be used by PeerConnectionInterface methods.

webrtc/api/peerconnectioninterface.h

Index: webrtc/api/peerconnectioninterface.h
diff --git a/webrtc/api/peerconnectioninterface.h b/webrtc/api/peerconnectioninterface.h
index 54fae2b71107398b6938e1b4c2797c00044ce4c8..cd58ae445570fb8034c1731dc0502fab7eaba545 100644
--- a/webrtc/api/peerconnectioninterface.h
+++ b/webrtc/api/peerconnectioninterface.h
@@ -140,6 +140,38 @@ class MetricsObserverInterface : public rtc::RefCountInterface {
 
 typedef MetricsObserverInterface UMAObserver;
 
+// Enumeration to represent distinct classes of errors that an application
+// may wish to act upon differently. These roughly map to DOMExceptions in
+// the web API, as described in the comments below.
+enum class RtcError {

[hta-webrtc, 2016/12/09 10:13:16]

Almost every time I've had an error enum, there's been a "kNoError" at value
zero. It catches some errors, and it's occasionally useful to set as a default
or return as a function result.

[Taylor Brandstetter, 2016/12/09 18:39:07]

Ah yes, we do need that. Would have realized the first time I tried to use this.

+  // A supplied parameter is valid, but currently unsupported.
+  // Maps to InvalidAccessError DOMException.
+  UNSUPPORTED_PARAMETER,

[hta-webrtc, 2016/12/09 10:13:16]

Why the ALL_CAPS_YELLING_NAMES?

https://google.github.io/styleguide/cppguide.html#Enumerator_Names says that
it's preferable to name them like constants, not macros.

[Taylor Brandstetter, 2016/12/09 18:39:07]

The Chromium guide says to use this style, and I thought that's what we used:
https://chromium.googlesource.com/chromium/src/+/master/styleguide/c++/c++.md

[pthatcher1, 2016/12/10 02:14:44]

Yeah, we just had that discussion back in June.   To be sure, I just
double-checked the emails.  We decided to go the CHROME_WAY, for better or
worse.

On 2016/12/09 18:39:07, Taylor Brandstetter wrote:

+  // General error indicating that a supplied parameter is invalid.
+  // Maps to InvalidAccessError or TypeError DOMException depending on context.
+  INVALID_PARAMETER,
+  // Slightly more specific than INVALID_PARAMETER; a parameter's value was
+  // outside the allowed range.
+  // Maps to RangeError DOMException.
+  INVALID_RANGE,
+  // Slightly more specific than INVALID_PARAMETER; an error occurred while
+  // parsing string input.
+  // Maps to SyntaxError DOMException.
+  SYNTAX_ERROR,
+  // The object does not support this operation in its current state.
+  // Maps to InvalidStateError DOMException.
+  INVALID_STATE,
+  // An attempt was made to modify the object in an invalid way.
+  // Maps to InvalidModificationError DOMException.
+  INVALID_MODIFICATION,
+  // An error occurred within an underlying network protocol.
+  // Maps to NetworkError DOMException.
+  NETWORK_ERROR,
+  // The operation failed due to an internal error.
+  // Maps to OperationError DOMException.
+  INTERNAL_ERROR,
+};
+

[hta-webrtc, 2016/12/09 10:13:16]

I've found it wise to add an ostream& operator<< (ostream& stream, RTCError
error) right off the bat.

It turns out that you have to have one of those in order to support RTC_CHECK_EQ
on the type, and people will look at your code strangely if you do
RTC_CHECK(status == RtcError::something).

[Taylor Brandstetter, 2016/12/09 18:39:07]

Done.

 class PeerConnectionInterface : public rtc::RefCountInterface {
  public:
   // See http://dev.w3.org/2011/webrtc/editor/webrtc.html#state-definitions .