2 ms·
So, this discussion has already demonstrated how Java programmers get this stuff wrong. Kind of head shaking stuff. Here's a simple implementation. No exception
by cbsmith 13y ago
So, this discussion has already demonstrated how Java programmers get this stuff wrong. Kind of head shaking stuff. Here's a simple implementation. No exception handling logic (and some would no doubt quickly with allowing throws of Throwable), on the assumption that anything that actually generates an exception would actually be the kind of thing you'd not want to recover from, and it uses synchronous, single byte at a time (buffered) reads & writes, but it actually runs reasonably efficiently as compared to using most scripting languages.
https://gist.github.com/cbsmith/9755809 https://gist.github.com/cbsmith/9755809
- sfjailbird 13y ago> on the assumption that anything that actually generates an exception would actually be the kind of thing you'd not want to recover from In that case it does exactly the wrong thing, by declaring checked exceptions in the method signature, which client code will be forced to deal with. If you don't even understand how checked exceptions are supposed to work then no wonder you are hurting yourself on the language.
- cbsmith 13y ago> In that case it does exactly the wrong thing, by declaring checked exceptions in the method signature, which client code will be forced to deal with. > In that case it does exactly the wrong thing, by declaring checked exceptions in the method signature, which client code will be forced to deal with. > > If you don't even understand how checked exceptions are supposed to work then no wonder you are hurting yourself on the language. It's an error that you don't have a way to recover from. Reporting an error and leaving it to the client code (or in this case, the parent process) to deal with it, exactly as specified by the declaration of the method. That's actually exactly how exceptions are supposed to work.