Error Handling
10 views
Skip to first unread message
Symon Rottem
Oct 9, 2010, 12:45:57 PM10/9/10
to aspComet
Following on from the discussion started Issue #6 on GitHub:
I'm inclined to agree with both approaches; for any meta messages the
handling should be more specific since the structure of the response
message requires it.
For other messages we could do something in the message processor.
Another possibility would be to create an AspCometException class
deriving from Exception and catch that separately from other
exceptions. That would allow you to throw exceptions with a specific
message you want passed back in the response if the exception is an
AspCometException while other exceptions could be passed back with a
"server error" type of message.
From my perspective this would be fairly clean and would make sure
that the recipient knows that something went wrong but still got a
response. For example, with a publish (to a normal or service
channel) the server doesn't have to send back a response, but I think
it should if something went wrong.
Cheers,.
Symon.
I'm inclined to agree with both approaches; for any meta messages the
handling should be more specific since the structure of the response
message requires it.
For other messages we could do something in the message processor.
Another possibility would be to create an AspCometException class
deriving from Exception and catch that separately from other
exceptions. That would allow you to throw exceptions with a specific
message you want passed back in the response if the exception is an
AspCometException while other exceptions could be passed back with a
"server error" type of message.
From my perspective this would be fairly clean and would make sure
that the recipient knows that something went wrong but still got a
response. For example, with a publish (to a normal or service
channel) the server doesn't have to send back a response, but I think
it should if something went wrong.
Cheers,.
Symon.
Neil Mosafi
Oct 9, 2010, 12:55:20 PM10/9/10
to aspComet
Hmm why do we need to use exceptions to handle application errors
(e.g. non aspcomet ones)?
Say the client publishes a message to a channel, an event handler
picks that and tries to handle the message in some application
specific manner. Something goes wrong when handling the message. The
event handler can then send a message to the client indicating
something went wrong, using client.Enqueue().
(e.g. non aspcomet ones)?
Say the client publishes a message to a channel, an event handler
picks that and tries to handle the message in some application
specific manner. Something goes wrong when handling the message. The
event handler can then send a message to the client indicating
something went wrong, using client.Enqueue().
Wintermoose
Oct 9, 2010, 1:39:47 PM10/9/10
to aspComet
I think the processor should handle exceptions as a safety net. If
error happens in the application, the server should try to "stay in
the role" and reply in a way defined by the protocol (the same way IIS
generally does send a proper 500 http reply if the website does
something unexpected).
But that's just a safety measure. When it comes to handlers reporting
errors by throwing exception, I don't really have any strong opinion
for either way. I know in c++ it was a bad idea because of
performance, but I never really looked into the implications in c#.
If I had a choice for my project, I would prefer just utility method
for creating failed responses. But returning error through few layers
of method calls is always pain, so having a suitable exception class
in addition cannot hurt.
// Robert
error happens in the application, the server should try to "stay in
the role" and reply in a way defined by the protocol (the same way IIS
generally does send a proper 500 http reply if the website does
something unexpected).
But that's just a safety measure. When it comes to handlers reporting
errors by throwing exception, I don't really have any strong opinion
for either way. I know in c++ it was a bad idea because of
performance, but I never really looked into the implications in c#.
If I had a choice for my project, I would prefer just utility method
for creating failed responses. But returning error through few layers
of method calls is always pain, so having a suitable exception class
in addition cannot hurt.
// Robert
Symon Rottem
Oct 9, 2010, 2:43:40 PM10/9/10
to aspc...@googlegroups.com
Neil Mosafi
Oct 10, 2010, 1:21:16 PM10/10/10
to aspComet
So currently I believe the only way the application has to generate
exceptions is using event handlers. If one of those throws an
exception, the exception is currently swallowed by the EventHub. This
firstly allows subsequent event handlers to still receive the event,
and ensures that the meta handlers still perform their duty.
Is the proposal therefore to stop swallowing exceptions here and allow
them to bubble up to the MessagesProcessor which would handle them and
return a failure message? Not convinced about this being a good idea.
Some helper extension methods would possibly be a good idea... e.g
client.EnqueueError("Object reference not set to an instance of an
object") or whatever?
On Oct 9, 7:43 pm, Symon Rottem <s.rot...@gmail.com> wrote:
> Sounds like a good compromise to me.
>
> Symon.
>
> Symon Rottemhttp://blog.symbiotic-development.com
exceptions is using event handlers. If one of those throws an
exception, the exception is currently swallowed by the EventHub. This
firstly allows subsequent event handlers to still receive the event,
and ensures that the meta handlers still perform their duty.
Is the proposal therefore to stop swallowing exceptions here and allow
them to bubble up to the MessagesProcessor which would handle them and
return a failure message? Not convinced about this being a good idea.
Some helper extension methods would possibly be a good idea... e.g
client.EnqueueError("Object reference not set to an instance of an
object") or whatever?
On Oct 9, 7:43 pm, Symon Rottem <s.rot...@gmail.com> wrote:
> Sounds like a good compromise to me.
>
> Symon.
>
Symon Rottem
Oct 10, 2010, 2:23:14 PM10/10/10
to aspc...@googlegroups.com
Apologies - I missed how the EventHub is dealing with Publish events. Now that I've caught on I'm inclined to agree - wrap themessage handling code of each handler in a try-catch and publish an error message if something went wrong. And yes, a helper method to make this easier makes sense.
I do think expected problems (such as the one that started this thread in the first place - an unsubscribe request for a client who is not connected (could happen if the server state was lost through the application being cycled)) should explicitly be used, but for unexpected problems the error should be logged and a more generic message passed back to the client to let them know something unexpected happened.
Wintermoose
Oct 10, 2010, 3:15:09 PM10/10/10
to aspComet
Hi
I do have to apologize as well, I completely forgot the current
implementation of the EventHub actually catches the app exceptions.
And I agree that's the best (essentially you already do what I wanted,
just on different level).
I was pondering whether we should anyway implement a special
exception, which is not ignored by the EventHub, but instead breaks
the loop. But, I see both pros and cons, and I see both cases when you
would want to be able to abort further processing (language filter
drops the message) and when not (logging handler wants to see every
message). So let's leave it as it is, for now.
Speaking of helpers, what placement you guys prefer? Client extension,
Message extension, generic extension, or something like
AspComet.Helper class?
I do have to apologize as well, I completely forgot the current
implementation of the EventHub actually catches the app exceptions.
And I agree that's the best (essentially you already do what I wanted,
just on different level).
I was pondering whether we should anyway implement a special
exception, which is not ignored by the EventHub, but instead breaks
the loop. But, I see both pros and cons, and I see both cases when you
would want to be able to abort further processing (language filter
drops the message) and when not (logging handler wants to see every
message). So let's leave it as it is, for now.
Speaking of helpers, what placement you guys prefer? Client extension,
Message extension, generic extension, or something like
AspComet.Helper class?
Reply all
Reply to author
Forward
0 new messages