4 commits

Author	SHA1	Message	Date
Trevor Parscal	d8ee3c2c29	After much research on error objects, native = good, custom = bad ... Stack traces, line numbers, etc. All the approaches I've seen are bad hacks. This is the best way to go. Change-Id: Ib12e9d2ecfe610bcc89d046005e35cc13efa3d99	2012-08-08 10:48:53 -07:00
Trevor Parscal	b4de3ead08	Throw ve.Error instead of string literals ... Throwing strings is bad because it doesn't include a lot of important information that an error object does, such as a stack trace or where the error was actually thrown from. ve.Error inherits directly from Error. In the future we may create more specific subclasses and/or do custom stuff. Some interesting reading on the subject: * http://www.devthought.com/2011/12/22/a-string-is-not-an-error/ Change-Id: Ib7c568a1dcb98abac44c6c146e84dde5315b2826	2012-08-08 06:19:00 +02:00
Trevor Parscal	255ce870e2	Puttin' em white-spacers where they aught'a be ... function() -> function () ){ -> ) { Change-Id: I20a85fcf79d7aec64f7f2559e84c0279550d4eea	2012-08-06 18:52:19 -07:00
Trevor Parscal	53e9258280	Added ve.init.platform with MediaWiki and stand-alone implementations ... This should make it much simpler to keep MediaWiki specifics out of VisualEditor, which will in turn make it easier to integrate VisualEditor into another platform. Change-Id: I073e9737b37c28af889f2457d10b082cefd0d63b	2012-07-27 13:39:19 -07:00