Caliburn.Micro icon indicating copy to clipboard operation
Caliburn.Micro copied to clipboard

Consolidate error handling across different sorts of Actions

Open nigel-sampson opened this issue 10 years ago • 9 comments

Currently an exception thrown in a coroutine (a method returning either IEnumerable<IResult>, Task or Task<>) when invoked through Message.Attach has it's exceptions handled in Coroutine, any exceptions would appear in Coroutine.Completed.

This also affects the event aggregator with IHandleWithCoroutine and IHandleWithTask.

I consider this a potential issue because of the following

// Exception raised in Application.UnhandledException.
public void SampleMethod() { throw new InvalidOperationException(); }

// Exception raised in Coroutine.Completed
public Task SampleMethod() { throw new InvalidOperationException(); }

We could resolve this in two ways.

  1. Have Coroutine.Completed raise an unhandled exception event.
  2. Have Coroutine.Completed throw an exception on error.
  3. Do nothing but add some documentation.

If there is any change I'd like to get this into 3.0.0 as it suddenly cause new exceptions if they were previously being swallowed.

Thoughts?

nigel-sampson avatar Nov 29 '15 21:11 nigel-sampson

Since exception in option 2 causes unhandled exception event, there is no real difference between first two for me. I'm against option 3 as you have pretty nice solution (1 or 2) and nobody reads documentation.

altso avatar Nov 29 '15 22:11 altso

Yeah they should both cause the same outcome, it's about the implementation and any side affects.

I know some people (myself included) have hooked into the coroutine pipeline to add features from the old Caliburn such as filters. This would impact them pretty heavily.

nigel-sampson avatar Nov 29 '15 22:11 nigel-sampson

Interestingly we provide Coroutine.ExecuteAsync that will throw an exception if the coroutine fails. This method isn't used anywhere in the framework and is just a helper method.

Will definitely want to be consistent across the two approaches here.

nigel-sampson avatar Dec 13 '15 21:12 nigel-sampson

This one is proving a real pain to implement in a well designed manner. Having Coroutine.Completed throw an exception if there is an error won't work because SequentialResult catches it and swallows it by sending it back through the Completed events. All becomes rather complicated when Coroutine.ExecuteAsync becomes involved. Back to the drawing board.

nigel-sampson avatar Dec 22 '15 01:12 nigel-sampson

The more I think about this the more split I become on what the best solution could be. Not in terms of implementation but outcome. It might make more sense to leave the Task alone and let it fall to TaskScheduler.UnobservedException. Part of the reason I don't like this is we'd now have three different events for three different types of method errors.

Going to leave this here for discussion on potential ideas on best way to consolidate error handling in Caliburn.Micro.

nigel-sampson avatar Dec 27 '15 20:12 nigel-sampson

Pushing this to 4.0 suspect it need to be a breaking change.

nigel-sampson avatar May 09 '17 09:05 nigel-sampson

Is this issue related to this discussion?

gthvidsten avatar Jun 05 '17 10:06 gthvidsten

Just posted a reply on the question, while it doesn't look to be caused by this it certainly has something to consider when doing this work.

Ideally I think making the error handling separate from any current event means we can pipe all of the errors to the same place.

nigel-sampson avatar Jun 06 '17 01:06 nigel-sampson

Any idea when is this going to be handled?

soltrac avatar May 15 '19 07:05 soltrac