Tag Info

New answers tagged

0

I could also use a template to generate derived classes via tagging rather than actually generating a new class each time. Something like class BaseException { ... }; template<typename T> struct DerivedException : BaseException { using BaseException::BaseException; }; struct CyclicReference {}; Then I could employ throw ...


0

In C#, the way this is done is by adding metadata to your object's members in the form of property attributes, each of which is a class. There aren't that many of them; they embody categories of errors, and some of them take parameters. For example, to validate a class property as a number between 0 and 50, you might decorate the property with an attribute ...


1

Aside the type, you can usually specify a textual description. For instance, in a method SetPercentage(value) a error OutOfRangeError thrown when the value is inferior to zero, but also superior to one hundred. Same type—two different errors. The text of the error can then specify what went wrong specifically. For instance: if (value < 0) { raise ...


1

I believe the standard approach is to use an error code (of enum type) and an error message (of string type). The "code" makes it easy to programmatically identify a specific type of error (if(e.code === DIVIDE_BY_ZERO)), and the "message" makes it easy to show something meaningful to the user (std::cout << e.message). A new derived exception class ...


1

This question is indeed too broad to be answered by a single answer on any single StackExchange site. You might want to visit the Information Security site to read about the practical techniques that you will want to adopt for your software. Of course, you can probably find similar techniques discussed on this site or at StackOverflow, written from a ...


2

Short answer: Absolutely no guarantees can be made about a program that crashes (or in fact one that DOESN'T crash). If an application crashes, the entire program's data (and any other writable memory areas, files, databases, etc that this program MAY have touched) areas must be treated as "probably not correct". Long answer: Since there is absolutely no ...


4

The solution is a remote procedure call. The callee must run in its own process space. How exactly you achieve that is a fairly minor detail. I'd strongly suggest not inventing the wheel yourself. Not that you'd need this after you've "formally proven its correctness". Correct code doesn't cause segfaults.


0

If Dan's comment had been an answer then I would have voted for it, but since it isn't... There are 2 kinds of errors where recovery is pure luck, if you can even get far enough to attempt recovery. "Out of Memory" and "Out of Disk Space". Thus, most applications don't even try to recover if either of these happen. They simply crash. Like Dan's comment ...


0

How should the application ideally handle the situation where it is completely unable to write to its log? Say due to a lack of disk space, exhausted file handle count, or a permissions/access issue. If you cannot write to the logs, you cannot write to the logs. It's pretty much out of your control until the cause is identified and it's resolved. In the ...


4

One way is to maintain a 'system' log file that usually is kept empty, but is pre-allocated. Then, for truly serious errors, you write the error to this location that is guaranteed to be available (well...) and has enough space for messages to be written to it. This should use a different, and very simple, error-logging system to avoid errors in the logging ...


3

Replace the last log entry with a new log entry that says the log is full, and silently discard any subsequent log entries. This preserves the rest of the log, and provides an indicator of what happened to the lost log entries.


0

Computer programs as they grow on a large scale, become very complex. They act according to very precise logic (machine instructions), and there are many environmental factors which can affect this logic and change its direction. Then sometimes we just [can] catch an error has occurred and to understand the reason needs a deep analysis of the software and ...


5

Because whoever was in charge of the information system didn't consider it worthwhile to preserve this information. That is the basic reason in all such cases. However, many different motives can be behind that assumption (and in fact, they can be both reasonable and unreasonable). Someone didn't think that anything could go wrong at all. It is rare for ...


0

The only status codes you need from HTTP are 200 for Success and 500 for failure, so that you know whether you are having a successful conversation or not. (Perhaps also 404 if your API is not the only application running on your server.) Once a successful conversation has been established, then any other error that might happen has absolutely nothing to ...


6

Don't invent status codes You are not expected to invent your own response codes, since the point of the API is to use a standard interface any developer can understand. The fact that you maintain both the API and its client is irrelevant: since everyone can trace the calls to the API, everyone can implement a different client. The point of using standard ...


2

Error handling of an API is exactly the same as error handling of any web application. Exceptions should be logged to a central syslog server, and the central log should be reviewed on regular basis. If you use a framework, the framework should handle this for you. Sending e-mails through PHP every time an exception occurs is a risky path. What if ...


1

As the other answers pointed If you don't expect NULL, make it clear by throwing ArgumentNullException. In my view, when you are debugging the project it helps you to discover the faults in the logic of your program sooner. So now you are going to release your software: if you restore those NullRefrences checks, you don't miss anything on the logic of your ...



Top 50 recent answers are included