I have a set of web services (the server), and an app which consumes this (client). In this sort of relationship, should the server always throw exceptions (ie in the throw block, rethrow the caught exception), and the client catch this. Exceptions which the server can handle, it will deal with and not rethrow, but everything else will be thrown to the calling layer for further action (the consuming app can raise a msg box or whatever).
Is this a good example of an exception that can be dealt with: A file cannot be written because the directory requires special privileges, so if this raises an exception, the file is written somewhere which does not require admin rights.
Thanks
There are more than one type of error.
For errors that the client can correct and retry, give them instructions on what to correct.
For other errors, where retrying will make no difference, such as an unauthorized action, let the user know why they can't perform the action, and if there's anything they can do to change the matter.
As you suggested, if the client issues a request to update the record, and something on the server, out of the control of the client, occurs, but the server can recover, then don't notify the client. If you need to know, then have the server notify you.
If the error occurs on the server, but the server isn't able to recover, you definitely need to notify the client of the failure and to either notify you, or try again later. Again, the system should notify you.
That particular error sounds like a configuration problem on the server, so the client doesn't have any means of action and shouldn't be given that information.
I generally cover that kind of error under a generic error message ("System error, please contact your system administrator") and log the error on the server (for later inspection).
Related
I have the Positronic-IO setup on one of my servers, and am attempting to set it up on a second where I will actually be performing the OCR. I can get it to install, but when attempting to call the Export-ImageText I receive the subject mentioned error.
I recall having a difficult time to get it to work on the first server as well. I guess I should have taken better notes. Does this require a re-start of the server??
I'm developing a website in php and codeignitor with three collegues, we're using mysql database.
I know that insert can throw an exception due to constraint violation, connect the server can make exception too if the server is busy.
Now what are other exceptions that might occur ? I tried looking in the web and I'm surprised I didn't find what I want, My webapp is a link-sharing website with tags, votes, flags,comments, and search(by title and tags, no advanced search yet) .
PS
Obviously we're not going to handle errors(like bad sector) so exceptions is what we want here.
Other common errors are:
The various php-generated catchable fatal errors. See here. http://php.net/manual/en/errorfunc.constants.php
php's out of memory error, which you cannot catch.
php's maximum execution time error, also which you cannot catch.
all sorts of MySQL errors.
Many web application software developers create a last-chance error handler. It logs the error message and any available stack trace to a log file and presents a "sorry, that didn't work" page to the user.
As you might guess, it's best not to use MySQL to log errors, because if it's MySQL failing, it won't work.
This is a community wiki page. That means anybody can edit it.
I have the following use case:
message size: ~4kb
protocol type: considering MQTT
message queue server: considering RabbitMQ or Mosquitto
up to 50k msg / s arriving messages
each message is sent from a mobile client with various network connectivity
What I would like to know is: how is it better to have the system to ingest the messages?
A) expose the message queue server directly to the Internet, processes the messages later for consistency / validity (of course with a load balancer in front of the servers)
B) expose a server that can read the message in the native format, apply some basic validity checks and then queue the message to an internal message queue server
I'm leaning towards the second option but I have no real arguments for pro / cons of it vs first option so can you please advise on this one?
Thank you.
You question has two parts:
Whether or not to expose the message queue server to the internet
Whether or not to process the message immediately
For the first question, I would advice to put the server behind a firewall. As such, you will have more tools to protect your server against internet attacks.
For the second question, it depends on whether or not the server is required to inform the mobile about the message processing result and whether the result of the message processing should be known immediately:
In case you are not required to send a feedback to the mobile and the result of the message processing is not required to be executed immediately, I would advice to log the message then process later it in batch mode,
In case you are required to send back a feedback to the mobile but the message isn't required to be processed immediately, I would advice to execute a sanity check of the message, send back the feedback to the mobile then log the message for batch processing,
Otherwise, I would advice to execute the sanity check, process the message and send back feedback to the mobile.
In my advice, I have suggested to use batch mode over online mode as much as possible. When you operate in batch mode, you have more options to use efficiently your computing resources in a simple way.
I have an app that requires local users to Sync back to the SQL server periodically (event based, including upon Close/Exit).
My users have occasional internet/VPN issues that throw the expected "3146" error.
Problem:
When ODBC error is thrown, my app LOSES its mind (global variables are lost, etc.) and the app becomes utterly unusable. There are many subsequent layers of error messages thrown to my users, occasionally requiring a Ctl-Break to interrupt (or task manager).
Question:
I have an err_handler in every module that provides a structured error message. I am able to trap err_number "3146" in the err_handler module, where I attempt an abrupt "Application.Quit" (to avoid the subsequent err messages). I still get a couple subsequent err messages before the application fully terminates.
Is there a better approach to more gracefully handling "3146" errors?
Looking for some good ideas.
Thanks!
If you are handling the error then there should not be a problem. How you should be handling the error is to not do Application.Quit, you should actually do something about the error. A failed connection is not a reason to blow up your app.
Instead, think about caching data locally so that when the connection can be made you can perform your sync again. When you discover your connection failed, stop trying to connect, abort the syncing process, and tell your users "Hey, we couldn't sync now. You might be having VPN issues. Fix those and try to sync again." And all the while your data are still stored in your accdb so that if they go into work the next day and are hardwired into the network they can then sync successfully.
I'm writing some client/server software and I'm facing the following design issue. Normally, I use a VERIFY macro very liberally - if something is wrong in an user's machine, I want the software to fail and log the error so it can be fixed. I was never a fan of ignoring any kind of errors.
However, I'm now writing a server. If the server dies, many clients go down, so the server should die as little as possible. Therefore, I don't know how to treat some conditions that I'd treat as fatal exceptions otherwise.
For example, I get a network packet from an user who isn't logged in. Even though it shouldn't happen, I have enough experience to know "impossible" errors do happen from time to time. So I'm pretty sure if I do a fatal error on these cases, the server WILL crash eventually. On the other hand, I could log and ignore the error and continue, but I'm afraid some bugs may go undetected this way.
What would you do in a situation like this one?
If you can recover from the error, than obviously it wasn't fatal. I can't see the benefit of failing if you can log the error and continue execution - the most important thing is that you've captured the error on log. If you can recover and continue to operate as normal, than that is the best course.
You should implement in addition a notification system (server monitoring) that depending on the error level would notify you in varying degrees of urgency so you'd pick up as soon as possible on something time critical. There are generic system like that for servers, such as Nagios and Munin. You should have look at what they do and see if you can take something from them and implement / integrate it into your system.
Regardless, you should try to make sure client instances are as sandboxed as possible. A client thread going down shouldn't take down the entire server - ever (at least in theory).