vitalyd · HackerTrans

11 वर्ष पहलेdiscuss

Indeed, they have good marketing :). Don't get me wrong, I think Azul and its C4 GC is very nice. However, beyond some absolute best case on smallish heaps, I do not see it hitting guaranteed 20 micros on large server heaps. Also, Azul sacrifices some throughput in favor of minimizing GC latency, which is fine as most things need tradeoffs but should be mentioned (G1 also has lower throughput than parallel due to heavier write barriers).

vitalyd

11 वर्ष पहलेdiscuss

I know Azul, it doesn't guarantee pauses of 20 micros; <10 millis maybe. G1 isn't even close.

vitalyd

11 वर्ष पहलेdiscuss

What JVM stops threads for ~20 micros?

vitalyd

11 वर्ष पहलेdiscuss

>You are right, of course. You should definitely know the behavior and failure modes of every framework and library you call. And you should consult the documentation for that. But what you don't need to consult (or even necessary know) is the mapping of every method to every exception. You should look at the total set of all exceptions and handle the ones you can handle.

You keep stating this, but it doesn't make sense. By definition, for you to handle it somewhere requires knowing the entry point to the call chain that may throw exception(s) that you decide to handle. At this point, you're wrapping some method invocation with a catch block, are you not? If so, you need to know that this method throws these exceptions. Sure, in some cases you may not care which of the tens of methods in the call chain actually triggered a SocketException, but that's a specific case and doesn't solve the overall problem. What if there are several sockets involved in the operation and you want to reconnect just the failing one, for example? At some point, you're going to have to sink your error handling to the point where you have enough context to handle it, which invariably means it's not enough to know the general types of exceptions an entire framework/library throws.

vitalyd

11 वर्ष पहलेdiscuss

>As an example, imagine you're building an application that you know uses sockets. And it's in the requirements that your application must be able recover and re-attempt set of operations. So you look into what kinds of network and socket exceptions exist in your platform, framework, and libraries. From there you decide which ones you should trap and attempt to retry.

You need to decide where you're going to handle them, and this depends on how much context is required to handle them appropriately. Sometimes this may require doing it right at the point where the method is invoked that triggers the exception. Even if you decide to not handle the exception, you may still want to know the exceptions so you can rollback/adjust state/invariants before letting the exception continue unwinding.

vitalyd

11 वर्ष पहलेdiscuss

The ones you can handle is a subset of possibly thrown ones, which means you need to know the superset before deciding which ones to handle. You're just describing the handling strategy: pass on it or handle it. It doesn't obviate the need to know what's possible there.

vitalyd

11 वर्ष पहलेdiscuss

So this is more akin to panics, where you don't really care about handling the error but rather want to stop dead in the tracks. But take something like .NET's SocketException, which contains a SocketErrorCode property; you may very well want to take different action depending on the type of error this is. This may be as simple as changing the text of the error shown to user (with suggestions on how to fix), but could also be some code based recovery that takes different action depending on the type.

vitalyd

11 वर्ष पहलेdiscuss

Oh, I agree that TryParse is much better than Parse for cases where parsing is expected to fail. But that doesn't detract from having better error handling capabilities in places where it is needed (e.g. i/o). A lot of the .NET i/o APIs will throw 4-5 different types of exceptions, and as the article states, you need to cross reference docs to see which exceptions are possible on certain calls. It's easy to forget or miss because compiler will not care.

vitalyd

11 वर्ष पहलेdiscuss

Error handling is one of the harder aspects of software engineering, IMHO. For starters, those code paths are less tested than others. See this, for example: https://www.usenix.org/system/files/conference/osdi14/osdi14...

vitalyd

11 वर्ष पहलेdiscuss

uint.Parse vs TryParse misses the point. It's very true that doing proper error handling in C# requires more diligence and attention. I know people like to harp on checked exceptions in java, but if used properly, they at least help with the discoverability aspect.

The fact that you have 174 catch blocks in a very large codebase only reinforces the blog's point, which is you may be missing error handling blocks or you just have very general handlers.

comments