Realm-dotnet: Suggestion: Realm.Error event static

[nirinchev]

As a preparation for https://github.com/realm/realm-dotnet/issues/1158, we could consider making the error events static. I feel it will be easier to work with them when you don't have to subscribe every time you open a Realm.

[AndyDentFree]

This feels like it could go horribly wrong but maybe I am misunderstanding things. There are a few issues mentioned on this SO post

My feeling is that the main problem is that it's annoying to have to subscribe every time you open a new instance on the same Realm.

However, you don't necessarily want the same subscriptions to functionally different Realms.

When people write richer apps using different Realms in different roles, having static events would mean they would have to filter on sender, which is pushing unnecessary complexity into their app logic.

So, maybe we need a way to propagate event registration, as an option onto new instances on the same Realm?

[sushihangover]

Two cents: I currently have apps that have more than one Realm instance for different RealmConfigurations in order to minimize memory consumption, isolating static data or very dynamic data (artificial on-disk size inflation due to multiple thread access until a Compact can be done), etc... So I would prefer a way to isolate events with different handlers without filtering, ... (unless I misunderstood : don't have to subscribe every time you open a Realm 😕 )

[kristiandupont]

@sushihangover I am not sure I follow -- would you prefer handlers on the instances rather than subscribe once-static handlers? Off the top of my head I can't think of a situation where I'd keep specific error handlers for different realms. It should obviously be possible to determine which realm triggered the error, but you could do that by inspecting the sender argument, if you really do need special behavior

[AndyDentFree]

@kristiandupont you just added ammunition for my point as to why static is a bad idea ;-)

Setting a different handler for a given Realm is a once-off that vectors to the correct handling code and keeps that code small.

Having to filter on the sender means:

1. added runtime cost per notification
2. Mixing code concerns - you now have a central handler in the application code, which makes life really hard for someone writing a component that uses Realm.

[kristiandupont]

Runtime cost in an error notification is completely irrelevant as I see it, but #2 is a good point. If you are writing a library that relies on Realm, you could perceivably want to handle errors without affecting other users. Do the events belong on the configuration classes perhaps?

[nirinchev]

Both Java and Cocoa have global error handlers. Java has them in the configuration builder as well, but Cocoa doesn't. So from API alignment POV, it would make sense to make our events static.

Additionally, I feel ease of use is more important than correctness here. Now for every realm people open, they'd have to do the following:

var realm = Realm.GetInstance(syncConfig);
realm.Error += OnRealmError;
realm.GetSession().Error += OnSessionError;

// Do stuff

realm.Error -= OnRealmError;
realm.GetSession().Error -= OnSessionError;
realm.Dispose();

So, my feeling is that most people will simply skip error handling (because it's annoying), which might lead to unpredicted results. E.g. data being lost after application restart.

If we agree there's value, we might even add a Handled property for the EventArgs and invoke the handlers in reverse chronological order so that "inner" handlers get the chance to act first and prevent "outer" handlers from executing their logic.

[AndyDentFree]

I think @nirinchev has made a strong argument for an _easy_ default _global handler_ but I am still very concerned about that replacing the ability to have per-Realm overrides.

[nirinchev]

Session.Error is now static. I'll update the title and move to P1 to consider doing that for the Realm.Error event.