4 ms·

Coming from C# to Java, checked exceptions are the worst. There are so many layers that can fail even in a simple API call - network, database, permissions, mem

Coming from C# to Java, checked exceptions are the worst. There are so many layers that can fail even in a simple API call - network, database, permissions, memory, etc.. We're not going to handle each of those cases differently, if we were going to we could always catch the specific exception type explicitly. But usually it's fail the API call, catch the base exception, and report the relevant failure message. Fail fast, report, move on. Maybe there are other programming situations where you want to catch every possible type of exception and run some custom logic for each one? I'd be interested to hear about it.

quelltext 7y ago
My point was that if one wants a language that is explicit about what error types a method can cause (see the top-level comment I replied to) then checked exceptions aren't far off and in fact on the same track. The problem you describe may be an issue with checked exceptions but it would equally be one in any language with the aforementioned feature. > We're not going to handle each of those cases differently, if we were going to we could always catch the specific exception type explicitly. But you don't have to handle them differently. You can though and your method signatures will tell you what type of errors you might have to deal with. Some make sense to handle on the spot others don't. You don't get that with runtime only exceptions. With those you really don't know and can get all kinds of errors and so you expect all and then just catch all and deal with it or blow up/abort whatever is going on (which let's be honest is what most web services do). Is that good? Yeah, sometimes. It certainly is easier to do that instead of thinking about possible failure modes when you know you'll only end up logging the error and give up anyway. I'm not trying to be cheeky, it really is overkill to make full use of checked exception in some cases. Granted I haven't seen many great examples of checked exception usages so far but I wouldn't dismiss them because they don't mesh with what you're used to or with what's common in a given domain.

quelltext 7y ago

My point was that if one wants a language that is explicit about what error types a method can cause (see the top-level comment I replied to) then checked exceptions aren't far off and in fact on the same track. The problem you describe may be an issue with checked exceptions but it would equally be one in any language with the aforementioned feature. > We're not going to handle each of those cases differently, if we were going to we could always catch the specific exception type explicitly. But you don't have to handle them differently. You can though and your method signatures will tell you what type of errors you might have to deal with. Some make sense to handle on the spot others don't. You don't get that with runtime only exceptions. With those you really don't know and can get all kinds of errors and so you expect all and then just catch all and deal with it or blow up/abort whatever is going on (which let's be honest is what most web services do). Is that good? Yeah, sometimes. It certainly is easier to do that instead of thinking about possible failure modes when you know you'll only end up logging the error and give up anyway. I'm not trying to be cheeky, it really is overkill to make full use of checked exception in some cases. Granted I haven't seen many great examples of checked exception usages so far but I wouldn't dismiss them because they don't mesh with what you're used to or with what's common in a given domain.