Skiasharp: [QUESTION] Exceptions vs error return codes, by design?

[Ziriax]

This is similar to question #743, but that was more than a year ago 😉

During development, I noticed that sometimes exceptions are thrown (e.g. argument validation), but often null references are returned when something goes wrong (like in the native Skia code).

A .NET developer usually expects exceptions, so I guess either

• this is not yet implemented?
• the choice of using return values to indicate errors was by design (e.g. performance)?
• the binding generator doesn't have enough metadata to generate exception wrappers (like SharpDX does)?

Also - suppose I would want to make PR for this - since the API must be backwards compatible, I guess any effort to make this library more ".NET compliant" regarding exceptions, should be enabled by a run-time configuration toggle?

[mattleibow]

Yeah, this was a bit of a mistake in the original design. Changing it now it breaking.

But, we are open to ideas. Maybe we can help a few members better.

Did you have any ideas?

[Ziriax]

A possibility would be to provide a new namespace Xamarin.Rendering.Skia, with classes without the Sk prefix, e.g. Paint, Canvas, and these would throw exceptions? That would also make the naming conventions more like idiomatic .NET.

But of course, then you have two API interfaces, not ideal... However, these could be generated?

[mattleibow]

Closing this as a duplicate of #743

The real issue is that this is a breaking change and creating a new API is not really viable. Setting a runtime property is also not particularly useful because how do you handle conflicting requests? You may want exceptions but your library may expect null.

I live in regret.