search

henry-spanka / freeathome-api

Busch-Jaeger free@home API to control actuators
MIT License
45 stars 4 forks source link

Feature/error handling #12

Closed ZzAve closed 4 years ago

ZzAve commented 4 years ago

Introduce a GuardedClient, basically extending the @xmpp/Client, to allow for guarded processing of 'stanza' updates.

henry-spanka commented 4 years ago

Thanks, Looks Good. But what should we do if we encounter an error during the initial handshake with the Access Point or later on and the connection is interrupted? In your implementation it would broadcast an error message to the 'Client' but what if the message is ignored or a user connects to the API later on. Currently the API crashes if a critical error occurs. It's not the best way either but at least a client is aware of it because the API server is stopped.

ZzAve commented 4 years ago

I think that error handling is something that should occur in the client, not in the server /api. You are notified when something goes wrong by the api, and you can act on it as you wish. For the application (started by the bash file in the bin), a broadcasted error will result in an error being thrown.

I think my local time was f-ed up btw when I committed. I only committed late last night.

henry-spanka commented 4 years ago

Ah, yes. Sorry I didn't see the error handling in Application.ts.

Thank you!