Improve compilation exception experience

[tjanczuk]

Currently inline C# code compilation errors surface in the form of exceptions from edge.func. These exceptions are cryptic and not very helpful in diagnosing the root cause of the issue. What can be done to improve the experience?

A typical exception looks like this:

System.Reflection.TargetInvocationException: Exception has been thrown by the ta
rget of an invocation. ---> System.InvalidOperationException: Unable to compile
C# code.
----> Errors when compiling as a CLR library:
c:\Users\IrisDaniela\AppData\Local\Temp\zkdkmxtg.0.cs(8,13) : error CS0116: A na
mespace cannot directly contain members such as fields or methods
c:\Users\IrisDaniela\AppData\Local\Temp\zkdkmxtg.0.cs(13,54) : error CS1518: Exp
ected class, delegate, enum, interface, or struct
c:\Users\IrisDaniela\AppData\Local\Temp\zkdkmxtg.0.cs(19,57) : error CS1518: Exp
ected class, delegate, enum, interface, or struct
c:\Users\IrisDaniela\AppData\Local\Temp\zkdkmxtg.0.cs(24,29) : error CS1022: Typ
e or namespace definition, or end-of-file expected
----> Errors when compiling as a CLR async lambda expression:
c:\Users\IrisDaniela\AppData\Local\Temp\m443fgbp.0.cs(2,7) : warning CS0105: The
 using directive for 'System.Threading.Tasks' appeared previously in this namesp
ace
c:\Users\IrisDaniela\AppData\Local\Temp\m443fgbp.0.cs(12,13) : error CS1643: Not
 all code paths return a value in lambda expression of type 'System.Func<object,
System.Threading.Tasks.Task<object>>'
c:\Users\IrisDaniela\AppData\Local\Temp\m443fgbp.0.cs(15,32) : warning CS1998: T
his async method lacks 'await' operators and will run synchronously. Consider us
ing the 'await' operator to await non-blocking API calls, or 'await Task.Run(...
)' to do CPU-bound work on a background thread.
c:\Users\IrisDaniela\AppData\Local\Temp\m443fgbp.0.cs(17,30) : warning CS0162: U
nreachable code detected
c:\Users\IrisDaniela\AppData\Local\Temp\m443fgbp.0.cs(17,68) : error CS0103: The
 name 'path' does not exist in the current context
   at EdgeCompiler.CompileFunc(IDictionary`2 parameters)
   --- End of inner exception stack trace ---
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments,
 Signature sig, Boolean constructor)
   at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Objec
t[] parameters, Object[] arguments)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invoke
Attr, Binder binder, Object[] parameters, CultureInfo culture)
   at ClrFunc.Initialize(Handle<v8::Value>* , Arguments* args)

[tjanczuk]

@irisclasson, @glennblock if you have ideas how to improve this experience, I am all ears.

Some background first. Edge allows two representations of inline C# code: a full class or class library code, or an async lambda expression. Edge attempts to compile the code first as a class library, and if that fails, as an async lambda expression. Only if both fail, an exception is thrown, like the above. That is why you see the two sections in that exception text: ----> Errors when compiling as a CLR library: and ----> Errors when compiling as a CLR async lambda expression:. Depending on what your intention was as a developer, one of these sections will contain the root cause of the problem.

[tjanczuk]

With the current support for structured exceptions, this could be addressed by throwing an AggregateException with inner exceptions having more fine grained details.