New answers tagged

1

I suggest to focus on persistence instead of dividing system: Try to use some network cache like Ehcache ( https://www.ehcache.org/ ) or fast non-relation database ( MongoDb ) instead of loading data into memory. This will allow to boot your system without spending time on filling in-memory data. Setup users session persistence, each JEE Server allows that....


0

It really depends on what the information is for, if the intermediate state changes need to be preserved. For example, the analytics team might care in which order items were added to the cart, at what time (and which parts of the web site were visited leading to additional purchases). They probably want to send a reminder to the user if the check-out was ...


1

I think the answer to your question comes from defining what the failure states for your application are. Event based systems come in a couple flavors: persistent queues and objects passed in memory. Both of those have different types of failure states. For example, persistent queues write the event to disk until a client confirms receipt. Objects passed ...


2

If this This means the web developer that is creating the GUI application would need to be in communication with the API devs... who may or may not be in the same time zone etc. is your core issue, your documentation is lacking. Microservices should be self-explanatory enough that barely any dev-to-dev communication is needed. Typically it's just an API ...


2

One option is to have 'Journey' or 'ProcessFlow' microservices where there are back-end micro-services that manage the process flow (or journey) through a state-machine. The state-machine captures the current process state of the end-user and provides an API where the front-end can query the possible next state. This removes the need for the front-end to ...


0

Assuming you have one client app running on 1000s of clients, making 750 million requests in total of 5 KB each. Let's say so that we have numbers, you have 25,000 client devices making 30,000 requests per week of 5KB each. Change if the numbers are different. The first cost is the cost for the clients, which is a bit tricky. You transfer 150 MB per client ...


1

To make such a calculation, you start by making a list of cost factors and find out the weekly costs for each of them: costs for your networking provider the hardware (renting price, or purchasing price divided by deprecation period, broken down to a price/week), including backup systems, backup storage systems etc. costs for any software required to run ...


4

It is a relevant question when hosting on cloud which may be the reason behind the question. There it is normal for each service have a price table e.g $ 0.05 for 1000 requests or something like that. If you are hosting on-prem the answer is amortized between the hardware. The people maintaining the hardware and the internet connection. In other words: if ...


-1

This cannot be more straightforward. There are only 3 types of code: Code that never throws an exception. Code that you know will generate exceptions. For example, connecting to an external RPC server, it is expected that sometimes it will timeout. You should add try...catch for this type of code. Code that you didn't expect, but does throw errors. Since ...


1

I know I am late to the party, but I think there is some nuance that is missing in the existing answers. To quote sage advice from any number of martial arts movies: The best way to block a punch is to not be there To bring it into software engineering, we can repurpose the quote this way: The best way to handle exceptions is to never throw them in ...


0

You have to consider the reason/purpose for handling an exception, such as: To perform some sort of corrective or recovery action so that the application can meaningfully continue; this implies that the exception and its consequences are well understood To perform some sort of cleanup so the application is restored to a consistent state; again, the ...


1

There are two broad categories of exceptions: those that arise from the programmer's misuse of an API (e.g., invalid arguments) and those that arise from external causes (e.g., file not found). Exceptions from external causes should always be caught; exceptions from misuse of APIs should never be caught. This is because it's realistically achievable to avoid ...


2

There are actually two different types of exceptions that need to be handled differently. First of all there are the "Non-bonehead" exceptions like "File not found". These exceptions are kind of expected, even if you check for the files existence beforehand it doesn't prove that it will be there when you go to use it. These you typically catch as low/...


1

To add an extra bit of flavor: While you should allow your program to fail, it's not necessary that you make it fail catastrophically. If your language allows you create your own exceptions, a great approach is to do something like this (Python): # Exception is the base "user" exception class class MyAppException(Exception): pass class MySpecificError(...


2

Personally, I handle all exceptions. And email them to myself. It doesn't have to be email, you could just log them, but if you don't know what these errors are happening, how can you ever hope to correct them? By all means, try to recover, or gloss over the error - to the user, but not to yourself. For AJAX requests, this might mean sending a 500 ...


1

Exceptions (Boneheaded or not) are Exceptional If something is exceptional, by definition you have not considered it, nor know how to handle it. Think of it like this. The sales assistant on the checkout of a store knows how to sell stuff, perform exchanges, etc.. They do not know how to handle Reporter Interview. The correct approach is to throw an ...


1

An exception you don’t know how to handle at a particular place should not be handled there. It should be passed up the call stack until it can be handled properly. If it is not expected anywhere, there is at least some place where an operation can be canceled without causing a “wrong answer” or a crash.


13

You are absolutely correct. An exception in server-side application code ("boneheaded" or not) should not crash a web server. The confusion is because the articles are not clear about what it actually means to "catch" or "crash". If we followed advice never to catch "boneheaded exceptions", then a single application bug should bubble up and cause the whole ...


3

I am surprised. Especially for some (important!) use cases, like server-side code, I simply can't see why is catching such an exception suboptimal and why the application must be allowed to crash. There's nothing wrong with a crash, in fact, it can be very helpful to have an application crash early. @PaulDrappers answer of 'Can the program sensibly ...


170

Silent But Deadly When writing enterprise software, you will eventually learn an essential truth: the worst bug in the world is not one that causes your program to crash. The worst bug in the world is one which causes your program to silently produce a wrong answer that goes unnoticed but eventually produces a massive negative effect (with severe financial ...


29

It doesn't really matter if it's a "boneheaded" exception (e.g. a Java unchecked exception) or not. The only question is: "Can the program sensibly continue?" A "server" is a program that processes messages. Typically, each message is mostly independent from the others. That is: if there is an error processing on message, it makes sense to continue ...


8

I think that what you are failing to appreciate is that that the real-life consequences of errors can be much worse than simply having the server go down. Just for instance: Erasing a database that is essential to the functioning of a company Granting access to confidential information that shouldn't be granted Approving a financial transaction that shouldn'...


3

Your example demonstrates exactly why you shouldn't catch 'all possible' exceptions. If your GetExpiredBans call fails, your code simply carries on as if it had been sucessful. The unbanner server is up and running and looks good, but actually it's not working at all. Now if you know that RemoveBan occasionally fails due to a network problem for example, ...


14

You learned an important thing: Whenever you read a rule on the internet that must absolutely be followed, you must start thinking about it and decide for yourself whether you should follow the rule in your specific case or not. And you should also think about whether the rule as you understand it is a good rule or not. Here some rules that you can think ...


40

Exceptions should be allowed to crash the system if the system has been left in an unrecoverable undefined state. If you can't put the system back in a defined state that ensures data integrity and security then you crash so the system can be rebooted into that defined state. Whenever you catch an exception you're taking responsibility for doing all that ...


Top 50 recent answers are included