Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 06:25
    ejsmith synchronize #452
  • 06:25

    ejsmith on elastic7

    Minor (compare)

  • 06:00
    ejsmith synchronize #452
  • 06:00

    ejsmith on elastic7

    Add missing task id (compare)

  • Dec 13 22:43
    ejsmith synchronize #452
  • Dec 13 22:43

    ejsmith on elastic7

    More reindex job changes (compare)

  • Dec 13 15:46
    ejsmith synchronize #452
  • Dec 13 15:46

    ejsmith on elastic7

    Just retry 3 times (compare)

  • Dec 13 15:44
    ejsmith synchronize #452
  • Dec 13 15:44

    ejsmith on elastic7

    More log message changes (compare)

  • Dec 13 14:25
    niemyjski synchronize #452
  • Dec 13 14:25

    niemyjski on elastic7

    Added retry reindex for disconn… (compare)

  • Dec 13 14:09
    niemyjski synchronize #452
  • Dec 13 14:09

    niemyjski on elastic7

    Updated migration to retry sock… (compare)

  • Dec 13 04:51
  • Dec 13 03:28
    ejsmith synchronize #452
  • Dec 13 03:28

    ejsmith on elastic7

    Oops progress (compare)

  • Dec 13 03:04
    ejsmith synchronize #452
  • Dec 13 03:04

    ejsmith on elastic7

    More log formatting (compare)

  • Dec 13 02:02
    ejsmith synchronize #452
Eric J. Smith
@ejsmith
@niemyjski dang. Can’t believe I’ve been getting trolled for 8 years. :-)
@mgnslndh awesome!!
Magnus Lindhe
@mgnslndh
How about adding an event to ExceptionlessClient that will fire when any unhandled exception is caught by any of its event handlers (UnobservedTask, AppDomain, Dispatcher, Application). Before the exception is submitted as an error event. I could then have a chance to log it locally. Or perhaps there already is some functionality like this?
Magnus Lindhe
@mgnslndh
Actually I think that event should fire for errors before/after the crash dialog.
If I listen to the event that fires after the crash dialog I can log and perhaps decide to terminate the application.
Blake Niemyjski
@niemyjski
@mgnslndh We have a submiting event that fires before the error is queued for submission. It also has a flag that you can check to see if it’s Unhandled and you can also cancel it so it’s not submitted
Magnus Lindhe
@mgnslndh
But the event is never fired if the user press "Cancel" on the dialog.
Blake Niemyjski
@niemyjski
Could because they cancled it before submitting was called.
let me look
Magnus Lindhe
@mgnslndh
The flow I am looking for is to do some cleaning and then shutdown the application when I have an unhandled exception. I could subscribe to all the necessary events and do it that way but I thought it would be nice if Exceptionless could provide a single event when it knows there is an unhandled exception that has been submitted or not (cancel on dialog).
The dialog ask if the user wants to submit a crash report or not. Either way I want to shutdown the application. Since I am using Exceptionless it would be nice to hook into its flow instead of hooking up several other event handlers that must run after Exceptionless. I mean it can be done without Exceptionless but it would be easier to have a little less plumbing to think about.
Blake Niemyjski
@niemyjski
The reason you are seeing that behavior is because they are wiring up to OnSubmitting before you
so if you wired up to that event handler first (before you call Startup) it would be hit
We really only have that one event handler that gets called
and if you wire up to it first you will be good to go
Are you going to sbumit the errors before shutting down or just call shut down?
submission should happen when you call exit
Can you try this and let me know
Magnus Lindhe
@mgnslndh
I want the user to choose by showing the dialog. After the dialog I would like to shutdown. I would also like to have access to the Exception object that caused the crash.
Ok. Submission always occur on exit? I use Environment.FailFast() but I guess that could be a problem then.
Blake Niemyjski
@niemyjski
I’d recommend testing it but yes it should
We never tested fail fast with submission
You have access to all of that in the OnSubmission handler
we might need to abstract the showing of the dialog because you want to handle that yourself and exit.
Magnus Lindhe
@mgnslndh
But I still dont see how I could shutdown after the dialog has been shown if the error is not submitted.
Blake Niemyjski
@niemyjski
If you look at that ExceptionlessClient, the wpf extensions you can see the flow of what happens
currently, you’d have to show the dialog yourself
You’d have to register a handler on OnSubmitting (and show the dialog) and then to pass false to the Register(false) method which will prevent the wpf client from showing that dialog
that would give you complete control over this.
Magnus Lindhe
@mgnslndh
Yes. I'll have a look at it and maybe do a pull request. Would you consider a new event if I show a solution for it or would you rather prefer I solve it some other way?
Blake Niemyjski
@niemyjski
If we abstracted the showing of the dialog behavior, it would make this a bit easier
I beleive there is a recently opened github issue round this
I think it would be better to use the existing event, and be better to abstract the showing of the dialog in a generic way
Magnus Lindhe
@mgnslndh
Ah, so if I hook up my own handler and show the dialog and deal with the dialog result I can then shutdown for both "Submit" and "Cancel".
Blake Niemyjski
@niemyjski
yes :)
Magnus Lindhe
@mgnslndh
Ok, just a quick question then. Is it possible to get hold of the original Exception object somehow?
Blake Niemyjski
@niemyjski
it should be straight foward just make sure you pass Register(false) so we don’t show that dialog.. and then you’d have to show it..
yes
Magnus Lindhe
@mgnslndh
GetError() returns a model of the error and I have not found a property or method for accessing the original Exception.
Blake Niemyjski
@niemyjski
    private static void OnSubmittingEvent(object sender, EventSubmittingEventArgs e) {
        //error.ExceptionlessClientInfo.Platform = ".NET WPF";
        if (!e.IsUnhandledError)
            return;

        var exception = e.PluginContextData.GetException();

        if (Application.Current != null && !Application.Current.Dispatcher.CheckAccess())
            e.Cancel = !(bool)Application.Current.Dispatcher.Invoke(new Func<EventSubmittingEventArgs, bool>(ShowDialog), DispatcherPriority.Send, e);
        else
            e.Cancel = !ShowDialog(e);
    }
You’d have to get it from the plugin context which if you inspect it contains everything that the plugins have access to (same contexT)
Magnus Lindhe
@mgnslndh
Ah, the context. Great! Now, I can solve both my issues.
Blake Niemyjski
@niemyjski
we have some helper methods on it too
Magnus Lindhe
@mgnslndh
Thanks a bunch! :)
Blake Niemyjski
@niemyjski
no problem. If you have any questions or think something could be easier let us knwo
I think we could make the showing of the dialog easier by abstracting it/injecting it into the di system
Frank Ebersoll
@frankebersoll
happy bday @niemyjski
Eric J. Smith
@ejsmith
@frankebersoll @niemyjski went on a road trip to nasville this weekend.
last I talked to him he was drinking a bit too much, :-)
Sander Rijken
@srijken
good times :)