Code Design Decision – Always throw custom exceptions • Hacker News Board

Re: Code Design Decision – Always throw custom exceptions

#21

Post by rowls66 » Mon, Dec 19, 2022, 5:37 PM UTC

bcrosby95 wrote: post #14

zaphar wrote: post #13

Earlier quoted context omitted.

I think there are two kinds of exceptions in languages that have them as their error handling mechanism. 1. Exceptions you expect your consumers to handle. 2. Exceptions you don't expect your consumers to handle. The first one I would argue you should wrap third party exceptions. There is in nearly every case important context in your code that the thrower of the third party exception will not know and whoever is rea…

This is one of the problems with checked exceptions. The library author is in no position to expect me to handle an exception. Whether or not I can relies on the design of my system, which they have no window into.

That is true, so the library should throw the checked exception, and if the caller has no way to handle it, it should wrap the checked exception in an unchecked exception and throw the unchecked exception. Not too hard, and library clients that can handle some checked exceptions will be able to.

I hate libraries that only throw unchecked exceptions. It seems easier initially, but makes writing correct code more difficult.

Re: Code Design Decision – Always throw custom exceptions

#22

Post by sandinmyjoints » Mon, Dec 19, 2022, 5:41 PM UTC

BrandoElFollito wrote: post #20

hbrn wrote: post #8

Just because it's useful to wrap exceptions in 5% of the cases doesn't mean you should wrap the rest 95% just in case . YAGNI. 1. You don't know which exceptions will be raised in advance. Anything that involves IO can fail in a plethora of ways, and you don't even know which calls involve IO (e.g. a library might choose to cache something on disk). 2. Consumers of your code will not know how to deal with those excep…

> You don't know which exceptions will be raised in advance. > Most of exceptions are unrecoverable (that's why they are called exceptions), the best course of action is to crash, which happens by default. I prefer to propagate such unknown exceptions to a top-level catch to clanly log that something happened. I usually have two types of exceptions: the ones I expect at some point (a HTTP call failing for some reason…

I really wish English had different individual words for the concepts "known [problem] we should not worry about" and "[problems] I did not anticipate".

Re: Code Design Decision – Always throw custom exceptions

#23

Post by kitd » Mon, Dec 19, 2022, 5:42 PM UTC

cratermoon wrote: post #16

This idea can also be explored in the Go programming language. Go has an error type, not exceptions, but error checking famously can be rather verbose. Two cases to consider come to mind. First, the common pattern result, err := SomeFunc() if err != nil { return err } Here the code is just passing along the error to the caller, unchanged. Second, signaling errors ab initio result := // some calculation or behavior if…

IME, returning a "stringly-typed" error is only wrong if you don't provide enough context in the returned error message. You can describe what you were doing as an error message and pass it back up the stack, each layer adding their own context, ie what they were trying to do to what. At the top you (should) get a pretty complete picture of what went wrong and why. I have found this reasonable and proportionate for most scenarios.

Re: Code Design Decision – Always throw custom exceptions

#24

Post by BurningFrog » Mon, Dec 19, 2022, 5:46 PM UTC

This feels like a classic case of looking at benefits but not costs.

In that mindset, any non zero benefit to X means you must do X.

Re: Code Design Decision – Always throw custom exceptions

#25

Post by Sakos » Mon, Dec 19, 2022, 5:47 PM UTC

julik wrote: post #6

In short: if you have a meaningful recovery pathway for a particular exception this can be useful, but I found that 9 out of 10 exceptions/errors in code cannot be recovered from. This is checked exceptions all over again... Frankly, I usually do exactly the opposite. Most cases I've seen the exceptions that can arise are not widely known in advance, and for most spots where exceptions can be raised from I simply do…

We primarily use custom exceptions to add detail to our error logs while still remaining concise. Generic exceptions are exceptionally useless for trying to debug issues, I've found.

Re: Code Design Decision – Always throw custom exceptions

#26

Post by Traubenfuchs » Mon, Dec 19, 2022, 5:47 PM UTC

Always avoid throwing custom exceptions. Example: ResponseStatusException in the spring framework.

You can at any point throw ResponseStatusException + http status code + optional message, for example

    throw new ResponseStatusException(BAD_REQUEST, "resource must be in status EDITABLE, but is in status " + status);

You can also define an error handler for this exception type to convert it in whatever error response format you desire.

Writing custom exceptions for everything is the definition of overengineering, falls into the YAGNI trap and means kicking KISS with your feet.

Re: Code Design Decision – Always throw custom exceptions

#27

Post by tsimionescu » Mon, Dec 19, 2022, 5:50 PM UTC

cratermoon wrote: post #16

This idea can also be explored in the Go programming language. Go has an error type, not exceptions, but error checking famously can be rather verbose. Two cases to consider come to mind. First, the common pattern result, err := SomeFunc() if err != nil { return err } Here the code is just passing along the error to the caller, unchanged. Second, signaling errors ab initio result := // some calculation or behavior if…

The whole DomainError thing only makes sense if you expect someone to handle this error (and by handle, I mean doing something other than logging and aborting some operation), or if you are writing a very generic library. Otherwise, it is wasted time and extra complexity that makes the code harder to read.

Re: Code Design Decision – Always throw custom exceptions

#28

Post by aleksiy123 » Mon, Dec 19, 2022, 5:57 PM UTC

I think this only makes sense if the 3rd party is also throwing custom exceptions.

If you want to reduce coupling you should avoid throwing custom exceptions at all. Semantic information can go in the error message and log. The error type should be used to indicate to your program whether an error is recoverable, retriable or some other action needs to be taken. For example google on has 16 canonical error codes for all APIs.

https://github.com/googleapis/googleapis/blob/master/google/...

Re: Code Design Decision – Always throw custom exceptions

#29

Post by andix » Mon, Dec 19, 2022, 6:01 PM UTC

I agree with the first sentence. Your code should throw custom exceptions.

But it shouldn’t wrap other exceptions, if they are obvious. If library.readconfigfile(path) throws an IO exception while reading the file, just let it bubble up to the caller and don’t bother handling it. Just make sure your internal state is clean (catch..finally)

Re: Code Design Decision – Always throw custom exceptions

#30

Post by [deleted] » Mon, Dec 19, 2022, 6:13 PM UTC

Traubenfuchs wrote: post #26

Always avoid throwing custom exceptions. Example: ResponseStatusException in the spring framework. You can at any point throw ResponseStatusException + http status code + optional message, for example throw new ResponseStatusException(BAD_REQUEST, "resource must be in status EDITABLE, but is in status " + status); You can also define an error handler for this exception type to convert it in whatever error response fo…

[deleted]