New answers tagged

0

What I see here, that you want to catch a subset of possible errors and you rethrow what you did not want to catch. The right solution would be not catching what you don't want to catch, so you won't need to rethrow it. I am not sure what C# allows, because I never worked with that language, but my guess would be that wrapping your treatable exceptions with ...


-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

There is only one reason to catch An Exception - to do something "useful" with it. Question: Do you "screen" every telephone call that comes into your office building on the off-chance that it might be relevant to you and "throw back" [all] the ones that aren't? Of course not. It's the same with Exceptions. Catch those that you can usefully handle ...


4

There are two reasons for catching an exception To convert the exception to a different exception, so that internal implementation details are not exposed to users of a module. An example could be that you want to turn a Kubernetes "no such pod" exception into a more generic Repository exception "item not found". These catch clauses should be within the ...


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 ...


1

Although, I have posted the answer in stackoverflow site, that might be still helpful to post here. Assertions are used, When you want to stop the program immediately rather to proceed with an unwanted state. This is often related to the philosophy of the Fail-fast [ 1 ] system design. When there are certain possibilities of cascading failures (i.e. in ...


Top 50 recent answers are included