Why exceptions are bad

The result would probably a look cleaner; b be far more abstract, confusing, and overdesigned than it needed to be; and c contain a half-implemented broken implementation of the Either pattern.

This logic doesn't necessarily belong in your main logic, it belongs in a plugin, and the Either pattern helps you send it there. In the real world my class would probably do a little more exception handling. There is a certain amount of irreducible pain in dealing with the infinite number of things that might go wrong; all the language can do is give us the flexibility to organize the resulting pile of code as best we can.

So basically an Either is for returning a different ostensibly error type in a language that normally cares about the declared return type in a method signature? How would that work for passing the result to another method for analysis? Relax the rules there too? The type checker will confirm that other function accepts a Either Bad Good as its argument.

If you want to use a function that only takes a Good and returns a SomethingElse, call it in a "do" block and the call will be skipped if you got a Bad because in the Either monad, the Left value is used for short-circuit failure or use liftM to convert it to a function that takes a Either Bad Good and returns a Either Bad SomethingElse.

A lot of other languages had to bake in exception type checking as a weird special case, because even though the type of a function because that's really about when you can and cannot use it should depend on which exceptions it handles, they made that way too much hassle to actually enforce.

However, Haskell is still evolving, and people have also added a couple versions of the typical bypass-the-type-system exception trainwreck, for reasons that escape me.

Strilanc on May 30, prev next [—]. It depends on what you do in the error case. If you try to recover, then Either is better. If you fail fast, then throwing is better. The main problem with checked exceptions, at least in Java, is the clumsiness of doing things right.

Ideally every function would expose exceptions corresponding to useful error cases. Instead, because there's so much boilerplate involved in creating new exception types and wrapping exceptions as the proper type, programmers are more likely to swallow or blindly propagate. I believe making checked exceptions signifcantly better is as easy as adding two features to Java: - Easy wrapping. If you read the comments, the author wrote a comment that basically says this.

Exceptions should be used for fatal errors, not for recoverable errors. I think checked exception are indeed annoying, specifying what exception types can be thrown in the method documentation it's pretty much enough. However I don't think ugliness is the main reason why exception should be avoided as much as possible, I think is performance : You get a performance penalty when you throw exceptions. About the return values, since. NET 2. This is a common dogma in. If we're being fair a more accurate statement would be "you currently get a performance penalty when you throw exceptions in Microsoft's implementation of.

Exceptions are much faster in mono than Microsoft's. Claiming Exceptions are slow is like saying "Java is slow". Languages and language features aren't slow, implementations are. These are very interesting articles benjiweber and you are right, it depends of the implementation. My point is that there are some cases in which you can gain some speed by no throwing exceptions at all and TryParse is a perfect example of this at least in.

Also exception-handling blocks might prevent the Virtual Machine from inlining the method again, at least in. That was boring. PaulHoule on May 30, prev next [—]. Errors are bad. Errors don't respect encapsulation. If a system is composable, there's alway the chance that some subsystem is going to throw an error that wasn't anticipated. Things like Either[A,B] make me cringe because they're just like what we used to do back in the 's in C.

Read carefully: adding error handling has tripled the size of this code sample! That's what exceptions win for you Effectively you get the extra 6 lines of code written for you. You might argue that the default behavior of exceptions might not be exactly what you want, but it's much better than the first example I wrote Aborting is a better default behavior than barreling past an error.

Something an error code has over an exception is simplicity. The concept is so easy to grasp someone completely new to coding can learn how to use and apply error codes almost immediately. And guess what? It returns an error code. There are also plenty of rules and best practices that must followed like…. Even if you understand all of the exception-related concepts and jargon mentioned in the previous item, writing exception-safe code is still hard.

The potential for a thrown exception can be subtle. From a readability standpoint, this can be awful. There are some languages that are aggressive about making sure you follow the contract when it comes to exceptions. Java also has unchecked exceptions. Also in Java, if your function calls another function that throws an exception, you MUST either catch the exception or have a compatible exception specification on your function.

The compiler holds your hand a bit here. They just muddied the waters. On the other hand, if a function has a dynamic exception specification, it can only throw the types, or subtypes of the types, specified. Throwing anything else results in std::unexpected being called. Of course, this a runtime check, and it does nothing for us at compile time.

But that class was intended to be a base for exceptions thrown by the standard library. So how do you do know what needs to be caught when you call another function?

Unfortunately, you must turn to documentation, comments in code, and in the worst case, wading through actual source code. Nothing is free. When an exception occurs, there is a cost. Older compilers may impose some performance overhead when executing a block of code whether it throws or not.

Modern compilers only incur a performance cost when the exception actually occurs. Exceptions should be rare. When an exception occurs, the application needs to do more work to make the exception work than it would, say, a simple return statement.

And that means more code. In constrained embedded environments where every byte of program size is critical, this can be an automatic deal breaker. This is just one example where an exception could be used to control the flow of code. Fortunately large parts of the. NET runtime use this pattern for non-exceptional events, such as parsing a string, creating a URL or adding an item to a Concurrent Dictionary.

So onto the performance costs, I was inspired to write this post after reading this tweet from Clemens Vasters :. Full Benchmark Code and Results. Up front I want to be clear that nothing in this post is meant to contradict the best-practices outlined in the. Here are the full, raw results:. Is there a possible recovery for the RepositoryException? Fine, then do it. You should not forget to catch the RepositoryException if you want to handle it.

Moreover, you have to document that your method throws a RepositoryException. You have to take care about the exception handling. But you are much more flexible and relieved from the boilerplate code. But how do I know, that a method throws an unchecked exception? Yes, you are responsible to document unchecked exceptions carefully. There are two options:.

Some people state that JavaDoc should be used for unchecked exceptions and the throws clause only for checked exceptions. Moreover, you can still use JavaDoc additionally for further documentation about the exception. Use unchecked exceptions. They enable freedom and flexibility. Not the compiler.