New answers tagged

1

the recommendation is to prefer returning a result object than throwing an exception This is bad advice IMHO, because they are used in different circumstances. Using a result object when an exception is most appropriate is bad. If ValidateUserInput is not able to perform its task because (for example) the process is out of memory, then throwing an ...


3

There are use cases for both exceptions and result objects, so "cleanliness" of the code is dependent upon the use case. It all depends on how critical it is to stop the execution of the program. Exceptions are the hand grenades of programming. Pull the pin and throw it. The only thing to keep your application from blowing sky high is to catch it and handle ...


1

Methods which throws exceptions are not "honest". You can't recognize if a method is expected to fail or not, by looking at its signature. Compared to [older versions of] Java this was argued to be one of .Net's biggest failings. Java laces Exceptions right into the Method signature; .Net doesn't. Exception handling adds a lot of boiler plate code. ...


0

There are different ways of dealing with the described situation. And before you start a "best practice"-debate - none of them is "better" than the others in general, you need to evaluate which one fits best to your case. A simple solution for the case of an "exception" is by simply not catching the exception in some non-GUI code and let it bubble up to ...


5

I'm still not sure whether to use exceptions or guard clauses for dealing with invalid arguments. Guard clauses and exceptions aren't mutually-exclusive. Failing the condition in a guard clause is often grounds for throwing an exception. In a lot of ways, something like guard_against_none(value) is a shorthand for "throw something if value is None." It ...


Top 50 recent answers are included