8 ms·

Code Design Decision – Always throw custom exceptions

96 points by that_guy_iain 4y ago

CharlieDigital 4y ago
Addendum: write a useful exception message for future travelers that might need to review that stack. What was null? Why might it be null? Mis-configuration? Missing configuration? Can't load some data or connect to some system? Which setting should be verified? Give simple hints on what might have gone wrong to help future you.
xwowsersx 4y ago
One of the ways*
deleted 4y ago
[deleted]
teddyh 4y ago
Yes. The Python modules I write generally have: class Error(Exception): pass class FooError(Error): … and then, in the generic case: try: failing_external_function() except Exception as e: raise Error(*e.args) from e (And if the code encounters a foo situation, it explicitly raises FooError, possibly with extra parameters, etc.) It is really annoying to have to catch all of, say, socket.error, SSL errors, FileNotFound, etc. etc. in every call to some function in a module, if you use that module extensively. It’s much easier to just catch module.Error and be done with it. If you need to handle foo errors specially, you catch FooError.
- hbrn 4y ago
  What happens if function from another module calls failing_external_function()? Will you wrap it in another_module.Error? This sounds like viral boilerplate: any function that can fail forces all other functions in the stack trace to be wrapped. Seems quite unpythonic, the whole point of exceptions is to avoid this boilerplate by propagating. Are you just writing boilerplate to assign exceptions to modules? But this information is already present in the stack trace, what is the point? It's too generic to actually handle exceptions, and too redundant to provide debugging value.
  - teddyh 4y ago
    > What happens if function from another module calls failing_external_function()? Will you wrap it in another_module.Error? Yes? If you call a function in another module, generally you’ll always have to catch and handle errors specific to that module. If that module does not wrap its errors (like socket.error, FileNotFound, etc.), you’ll have to handle those, as well. And, like Parthenon points out, if that module ever changes its internal implementation, it will suddenly raise different errors, which your code does not catch. On the other hand, if the module wraps its errors, you’ll have a guarantee that you’ll be able to catch them. I don’t know why you keep bringing up debugging; Python’s “raise from” keeps the original exception intact and available. > Are you just writing boilerplate to assign exceptions to modules? Wait, are you talking about monkey-patching? I’m not doing that. I’m talking about the case where you write your own module for something, and then use that module in another program (possibly itself a module).
    - hbrn 4y ago
      Your code example essentially renames a regular wildcard Exception to module-specific wildcard exception. But here's a thing: For direct callers of your module, regular wildcard and module wildcard are exactly the same. There's absolutely no difference for them whether they are catching module.Error or Exception, because your code is structured so that mean exactly the same thing. For indirect callers higher in the stack, your custom wildcard exception makes error handling harder, because instead of familiar exceptions they will see your custom one. Your wrapper makes it harder to access what happened, but easier to access where it happened. This is just a bad tradeoff. In some cases for you where might be more valuable than what. But you are in no position to assume that this is how it's going to be for your customers. Examples where this practice might be useful (e.g. explicitly shifting the blame to a 3rd party) are simply too rare to justify those wrappers. You could still achieve the same results by inspecting the stack, without impeding the ability of your customers to deal with known exceptions.
      - teddyh 4y ago
        > For direct callers of your module, regular wildcard and module wildcard are exactly the same. Well, no. I usually only wrap exceptions which I know to possibly expect, and only wrap ‘Exception’ in code sections where I know I want to catch any exception, no matter what (which is rare, but happens). Unexpected exceptions (either of an unexpected type or in an unexpected place) will still propagate upwards. This allows the code calling my module to catch any reasonably expected exceptions (since I will wrap them in my module.Error, or, really, a more specifc exception class inhereting from module.Error), while still allowing unexpected exceptions to be shown. I realize that I was unclear in my initial description; I do not catch ‘Exception’ all the time, but only occasionally. I most often list the exceptions which I know that the called function could raise in failure states which I know how to handle. > Your wrapper makes it harder to access what happened How? With “raise from”, Python shows you not only the stack trace of the error, but also the stack trace of the original exception, IIRC.
julik 4y ago
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 not care about them as much either. If my DB is not accessible - do I really, really need to wrap it? If the DNS resolver is failing - do I really really need to wrap it? When debugging I actually appreciate when a library/controller/module/whatnot does not attempt to "enhance" the exception from something outside of its control with a wrapper, and value seeing the original failure instead.
- teddyh 4y ago
  > I […] value seeing the original failure instead This is what Python’s “raise from” is for; to preserve the original exception.
- rileymat2 4y ago
  > This is checked exceptions all over again... That is an interesting topic, as I went through the cycle of adding and removing them, they always felt like the right thing, but they felt like "work". They make coding less fun, having to think through failure conditions, like you say, you don't care about. I guess the answer is really there is no one sized fits all solution, we have some applications where the correct solution is to crash, we have other applications that can't crash under any condition. You just need to know where you are. Edit: Also, out of the box C++ checked exceptions implemented terribly. http://www.gotw.ca/publications/mill22.htm http://www.gotw.ca/publications/mill22.htm The (Mis)understanding section describes it pretty well.
  - Rexxar 4y ago
    "exception specifications" are deprecated since c++11 and completely removed in c++17 if I'm not mistaken.
    - 4y ago
hbrn 4y ago
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 exceptions. 3. Most of exceptions are unrecoverable (that's why they are called exceptions), the best course of action is to crash, which happens by default. 4. You debug those exceptions by looking at stack trace. Adding extra levels just to give a fancy meaningless name to an exception does not help. 5. The whole point of exceptions is to propagate. Parthenon essentially suggests converting exceptions into return values.
- zaphar 4y ago
  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 reading or handling the exception will want to know. The second one should do whatever the equivalent of crashing is for your use case. Either exiting the program hard or bubbling to some top level handler where a "Something weird and unexpected happened and we can't continue whatever action was going on" alert or log get's recorded and the activity is terminated. If something is throwing an exception and you don't know it can be throwing an exception it probably belongs in category 2. You may over time transition it to category 1 when you figure out that it is actually handleable. In my experience though if you aren't disciplined then every exception ends up being lumped into category 2 whether it should be or not. Any language that helps you force the categorization gets bonus points from me.
  - bcrosby95 4y ago
    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.
greatpostman 4y ago
Like others have said, in theory this is great. In reality, I never see custom exceptions being handled differently than whatever exception was wrapped. And I have worked on some large distributed systems where failure is common. For new engineers these custom exceptions add abstract complexity and exception class hierarchy into a code base when it really isn’t needed.
- IshKebab 4y ago
  I disagree. I have seen plenty of code that is forced to match on the text of an exception because it uses a too-generic type. That said, I still wouldn't use a custom exception type in most languages simply because it's so tedious for a small pay-off. It's one of those things that you should do, but isn't really worth the hassle. Like putting alt text on HTML images. Do any languages with exceptions let you define new exception types at the throw site?
  - Psyonic 4y ago
    I don't see how an exception type defined at the throw site would be significantly different than using the text of the exception to convey the type. Callers wouldn't know to expect it either way, so how would they be able to handle it effectively?
- vbezhenar 4y ago
  YAGNI principle should be followed here. Do not throw custom exception until you need it. If the time arises, do a simple refactoring. For libraries that's more nuanced and good unchecked exception hierarchy is a part of good API.
DotaFan 4y ago
I only throw exceptions to the flows that are not in my control (backend API, external libraries, IO).
cratermoon 4y ago
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 result != expected return fmt.Errorf("An error happened. Expected %v, go %v", expected, result) In the first case, the discussions around whether or not to throw custom exceptions applies analogously: should you wrap the error or not? The second case, I argue, is always wrong. The error is "stringly typed", and can be examined and read by a person, but that's it. The correct way is to define an error type meaningful for the context. Errors in Go are type implementing the error interface type error interface { Error() string } therefore, an error should be a type relevant or the context. A useful starting point looks something like type DomainError struct { Code DomainErrorCode Message string Details []DomainType } func (d DomainError) Error() string { return Message } then code can look like // some work if result != expected { return DomainError { Status: AnErrorCode Message: fmt.Sprintf("Error %v. Expected %v, go %v", AnErrorCode expected, result) Details: []DomainType{ expected, result } } } And the caller gets back a type providing useful information.
- kitd 4y ago
  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.
  - cratermoon 4y ago
    That's all well and good if all you want to do it propagate the error up the call stack until some code prints it, but that's not really handling the error, any more than if err != nil { return error } is. If the calling code needs to behave differently depending on the details of the error, the worst way to do that would be examine the message string. A robust system is going to respond very differently if, for example, the error is one that indicates retrying is worthwhile vs an error indicating that no amount of retrying will ever succeed.
BurningFrog 4y ago
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.
Traubenfuchs 4y ago
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.
- deleted 4y ago
  [deleted]
andix 4y ago
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)
aleksiy123 4y ago
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/rpc/code.proto https://github.com/googleapis/googleapis/blob/master/google/...
klntsky 4y ago
This is a reasonable approach, but having a catch-all case that handles the exception and re-throws it, but wrapped in custom exception type can be problematic in case a new exception is added - the consumer of the API needs to go over their code and change the types everywhere, or else their catch code will not be working as before anymore. This problem can easily go unnoticed, judging by my Haskell experience. The solution would be to always use "checked exceptions" (or similar concept in your language, e.g. `ExceptT SomeEnumType` in Haskell) and never use catch-all cases (or wildcard patterns, in case of Haskell), so that every exception handling case is tagged with exception type, and type-checked.
MrTortoise 4y ago
Amazes me that so many people dont understand that if all things are dependant upon your business logic or on your domain then this is natural. Its natural hex architecture but this is far nicer way of saying the same thing https://ericlippert.com/2008/09/10/vexing-exceptions/ https://ericlippert.com/2008/09/10/vexing-exceptions/ I actually do not think your code should throw exceptions. It is really just an Either / result and then if something does blow its because you havent anticipated it via wrapping something in an either or result ... and so it should blow and the callers of your library should be submitting a defect..
KronisLV 4y ago
There are some nice arguments for not overengineering in the comments here, as well as some for there still being merit in explicitly saying what could (typically) go wrong in the execution of a program. We've already seem the extreme of "never create your custom exceptions", or even something to the tune of "exception handling is a maintenance burden", but I can't help but to wonder about going in the exact opposite direction - even further than the article suggests. What if we had a language that only had checked exceptions and forced you to deal with anything that can go wrong. Launching a program? You better have some code to deal with an out of memory exception, or some code for dealing with a stack overflow exception. Working with some maths? Well, you better define what should happen in the case of number underflows or overflows, as well as division by zero or whatever else can be inferred by what operators you use. Dealing with a network? Well, be prepared to handle dozens of types of network failures, the brittleness of networks being laid bare to you. Want to deal with reflection? Well, there would probably be none, to avoid too much dynamic behavior. It's rather obvious why we don't really have languages like that, but at the same time - if writing code in a language like that would be "possible", then surely there's a domain or two out there that might benefit not just from enforced 100% test coverage, but also every single possible error being handled, or at least laid bare. If a program should crash upon particular errors, then the developer might say so explicitly, or otherwise provide logic to recover from those, without ever missing any place where things could go wrong. Contrast this made up language with your typical Java project: you might use the Spring framework and have a method that exposes a RESTful API that returns some JSON to the client. You'd be amazed at just how many different issues you can run into with even the simplest implementations, it's like a never ending path of discovering more ways for your programs to go wrong. If you can sometimes benefit from your IDE going "hey, this code might throw a NullPointerException", then how much additional assistance you'd benefit from (and how much error handling should be encouraged/enforced) is probably up for debate!
- lmm 4y ago
  > What if we had a language that only had checked exceptions and forced you to deal with anything that can go wrong. Launching a program? You better have some code to deal with an out of memory exception, or some code for dealing with a stack overflow exception. Working with some maths? Well, you better define what should happen in the case of number underflows or overflows, as well as division by zero or whatever else can be inferred by what operators you use. Dealing with a network? Well, be prepared to handle dozens of types of network failures, the brittleness of networks being laid bare to you. Want to deal with reflection? Well, there would probably be none, to avoid too much dynamic behavior. > It's rather obvious why we don't really have languages like that, but at the same time - if writing code in a language like that would be "possible", then surely there's a domain or two out there that might benefit not just from enforced 100% test coverage, but also every single possible error being handled, or at least laid bare. If a program should crash upon particular errors, then the developer might say so explicitly, or otherwise provide logic to recover from those, without ever missing any place where things could go wrong. A lot of functional languages go in that direction. E.g. if you stick to the non-IO fragment of Haskell then it mostly works like that - things that can error return Either that you have to handle explicitly, and while there's sugar to let you work with that in a similar way to exceptions it will never be entirely hidden. (Within IO you can have exceptions, of course; making a proper algebraic model of how e.g. network I/O works is pretty daunting). Idris or especially Noether go even further in that direction.

96 points by that_guy_iain 4y ago

Addendum: write a useful exception message for future travelers that might need to review that stack. What was null? Why might it be null? Mis-configuration? Missing configuration? Can't load some data or connect to some system? Which setting should be verified? Give simple hints on what might have gone wrong to help future you.

xwowsersx 4y ago

One of the ways*

deleted 4y ago

[deleted]

teddyh 4y ago

Yes. The Python modules I write generally have: class Error(Exception): pass class FooError(Error): … and then, in the generic case: try: failing_external_function() except Exception as e: raise Error(*e.args) from e (And if the code encounters a foo situation, it explicitly raises FooError, possibly with extra parameters, etc.) It is really annoying to have to catch all of, say, socket.error, SSL errors, FileNotFound, etc. etc. in every call to some function in a module, if you use that module extensively. It’s much easier to just catch module.Error and be done with it. If you need to handle foo errors specially, you catch FooError.

hbrn 4y ago
What happens if function from another module calls failing_external_function()? Will you wrap it in another_module.Error? This sounds like viral boilerplate: any function that can fail forces all other functions in the stack trace to be wrapped. Seems quite unpythonic, the whole point of exceptions is to avoid this boilerplate by propagating. Are you just writing boilerplate to assign exceptions to modules? But this information is already present in the stack trace, what is the point? It's too generic to actually handle exceptions, and too redundant to provide debugging value.
- teddyh 4y ago
  > What happens if function from another module calls failing_external_function()? Will you wrap it in another_module.Error? Yes? If you call a function in another module, generally you’ll always have to catch and handle errors specific to that module. If that module does not wrap its errors (like socket.error, FileNotFound, etc.), you’ll have to handle those, as well. And, like Parthenon points out, if that module ever changes its internal implementation, it will suddenly raise different errors, which your code does not catch. On the other hand, if the module wraps its errors, you’ll have a guarantee that you’ll be able to catch them. I don’t know why you keep bringing up debugging; Python’s “raise from” keeps the original exception intact and available. > Are you just writing boilerplate to assign exceptions to modules? Wait, are you talking about monkey-patching? I’m not doing that. I’m talking about the case where you write your own module for something, and then use that module in another program (possibly itself a module).
  - hbrn 4y ago
    Your code example essentially renames a regular wildcard Exception to module-specific wildcard exception. But here's a thing: For direct callers of your module, regular wildcard and module wildcard are exactly the same. There's absolutely no difference for them whether they are catching module.Error or Exception, because your code is structured so that mean exactly the same thing. For indirect callers higher in the stack, your custom wildcard exception makes error handling harder, because instead of familiar exceptions they will see your custom one. Your wrapper makes it harder to access what happened, but easier to access where it happened. This is just a bad tradeoff. In some cases for you where might be more valuable than what. But you are in no position to assume that this is how it's going to be for your customers. Examples where this practice might be useful (e.g. explicitly shifting the blame to a 3rd party) are simply too rare to justify those wrappers. You could still achieve the same results by inspecting the stack, without impeding the ability of your customers to deal with known exceptions.
    - teddyh 4y ago
      > For direct callers of your module, regular wildcard and module wildcard are exactly the same. Well, no. I usually only wrap exceptions which I know to possibly expect, and only wrap ‘Exception’ in code sections where I know I want to catch any exception, no matter what (which is rare, but happens). Unexpected exceptions (either of an unexpected type or in an unexpected place) will still propagate upwards. This allows the code calling my module to catch any reasonably expected exceptions (since I will wrap them in my module.Error, or, really, a more specifc exception class inhereting from module.Error), while still allowing unexpected exceptions to be shown. I realize that I was unclear in my initial description; I do not catch ‘Exception’ all the time, but only occasionally. I most often list the exceptions which I know that the called function could raise in failure states which I know how to handle. > Your wrapper makes it harder to access what happened How? With “raise from”, Python shows you not only the stack trace of the error, but also the stack trace of the original exception, IIRC.

julik 4y ago

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 not care about them as much either. If my DB is not accessible - do I really, really need to wrap it? If the DNS resolver is failing - do I really really need to wrap it? When debugging I actually appreciate when a library/controller/module/whatnot does not attempt to "enhance" the exception from something outside of its control with a wrapper, and value seeing the original failure instead.

teddyh 4y ago
> I […] value seeing the original failure instead This is what Python’s “raise from” is for; to preserve the original exception.
rileymat2 4y ago
> This is checked exceptions all over again... That is an interesting topic, as I went through the cycle of adding and removing them, they always felt like the right thing, but they felt like "work". They make coding less fun, having to think through failure conditions, like you say, you don't care about. I guess the answer is really there is no one sized fits all solution, we have some applications where the correct solution is to crash, we have other applications that can't crash under any condition. You just need to know where you are. Edit: Also, out of the box C++ checked exceptions implemented terribly. http://www.gotw.ca/publications/mill22.htm http://www.gotw.ca/publications/mill22.htm The (Mis)understanding section describes it pretty well.
- Rexxar 4y ago
  "exception specifications" are deprecated since c++11 and completely removed in c++17 if I'm not mistaken.
  - 4y ago

hbrn 4y ago

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 exceptions. 3. Most of exceptions are unrecoverable (that's why they are called exceptions), the best course of action is to crash, which happens by default. 4. You debug those exceptions by looking at stack trace. Adding extra levels just to give a fancy meaningless name to an exception does not help. 5. The whole point of exceptions is to propagate. Parthenon essentially suggests converting exceptions into return values.

zaphar 4y ago
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 reading or handling the exception will want to know. The second one should do whatever the equivalent of crashing is for your use case. Either exiting the program hard or bubbling to some top level handler where a "Something weird and unexpected happened and we can't continue whatever action was going on" alert or log get's recorded and the activity is terminated. If something is throwing an exception and you don't know it can be throwing an exception it probably belongs in category 2. You may over time transition it to category 1 when you figure out that it is actually handleable. In my experience though if you aren't disciplined then every exception ends up being lumped into category 2 whether it should be or not. Any language that helps you force the categorization gets bonus points from me.
- bcrosby95 4y ago
  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.

greatpostman 4y ago

Like others have said, in theory this is great. In reality, I never see custom exceptions being handled differently than whatever exception was wrapped. And I have worked on some large distributed systems where failure is common. For new engineers these custom exceptions add abstract complexity and exception class hierarchy into a code base when it really isn’t needed.

IshKebab 4y ago
I disagree. I have seen plenty of code that is forced to match on the text of an exception because it uses a too-generic type. That said, I still wouldn't use a custom exception type in most languages simply because it's so tedious for a small pay-off. It's one of those things that you should do, but isn't really worth the hassle. Like putting alt text on HTML images. Do any languages with exceptions let you define new exception types at the throw site?
- Psyonic 4y ago
  I don't see how an exception type defined at the throw site would be significantly different than using the text of the exception to convey the type. Callers wouldn't know to expect it either way, so how would they be able to handle it effectively?
vbezhenar 4y ago
YAGNI principle should be followed here. Do not throw custom exception until you need it. If the time arises, do a simple refactoring. For libraries that's more nuanced and good unchecked exception hierarchy is a part of good API.

DotaFan 4y ago

I only throw exceptions to the flows that are not in my control (backend API, external libraries, IO).

cratermoon 4y ago

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 result != expected return fmt.Errorf("An error happened. Expected %v, go %v", expected, result) In the first case, the discussions around whether or not to throw custom exceptions applies analogously: should you wrap the error or not? The second case, I argue, is always wrong. The error is "stringly typed", and can be examined and read by a person, but that's it. The correct way is to define an error type meaningful for the context. Errors in Go are type implementing the error interface type error interface { Error() string } therefore, an error should be a type relevant or the context. A useful starting point looks something like type DomainError struct { Code DomainErrorCode Message string Details []DomainType } func (d DomainError) Error() string { return Message } then code can look like // some work if result != expected { return DomainError { Status: AnErrorCode Message: fmt.Sprintf("Error %v. Expected %v, go %v", AnErrorCode expected, result) Details: []DomainType{ expected, result } } } And the caller gets back a type providing useful information.

kitd 4y ago
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.
- cratermoon 4y ago
  That's all well and good if all you want to do it propagate the error up the call stack until some code prints it, but that's not really handling the error, any more than if err != nil { return error } is. If the calling code needs to behave differently depending on the details of the error, the worst way to do that would be examine the message string. A robust system is going to respond very differently if, for example, the error is one that indicates retrying is worthwhile vs an error indicating that no amount of retrying will ever succeed.

BurningFrog 4y ago

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.

Traubenfuchs 4y ago

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.

deleted 4y ago
[deleted]

andix 4y ago

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)

aleksiy123 4y ago

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/rpc/code.proto https://github.com/googleapis/googleapis/blob/master/google/...

klntsky 4y ago

This is a reasonable approach, but having a catch-all case that handles the exception and re-throws it, but wrapped in custom exception type can be problematic in case a new exception is added - the consumer of the API needs to go over their code and change the types everywhere, or else their catch code will not be working as before anymore. This problem can easily go unnoticed, judging by my Haskell experience. The solution would be to always use "checked exceptions" (or similar concept in your language, e.g. `ExceptT SomeEnumType` in Haskell) and never use catch-all cases (or wildcard patterns, in case of Haskell), so that every exception handling case is tagged with exception type, and type-checked.

MrTortoise 4y ago

Amazes me that so many people dont understand that if all things are dependant upon your business logic or on your domain then this is natural. Its natural hex architecture but this is far nicer way of saying the same thing https://ericlippert.com/2008/09/10/vexing-exceptions/ https://ericlippert.com/2008/09/10/vexing-exceptions/ I actually do not think your code should throw exceptions. It is really just an Either / result and then if something does blow its because you havent anticipated it via wrapping something in an either or result ... and so it should blow and the callers of your library should be submitting a defect..

KronisLV 4y ago

There are some nice arguments for not overengineering in the comments here, as well as some for there still being merit in explicitly saying what could (typically) go wrong in the execution of a program. We've already seem the extreme of "never create your custom exceptions", or even something to the tune of "exception handling is a maintenance burden", but I can't help but to wonder about going in the exact opposite direction - even further than the article suggests. What if we had a language that only had checked exceptions and forced you to deal with anything that can go wrong. Launching a program? You better have some code to deal with an out of memory exception, or some code for dealing with a stack overflow exception. Working with some maths? Well, you better define what should happen in the case of number underflows or overflows, as well as division by zero or whatever else can be inferred by what operators you use. Dealing with a network? Well, be prepared to handle dozens of types of network failures, the brittleness of networks being laid bare to you. Want to deal with reflection? Well, there would probably be none, to avoid too much dynamic behavior. It's rather obvious why we don't really have languages like that, but at the same time - if writing code in a language like that would be "possible", then surely there's a domain or two out there that might benefit not just from enforced 100% test coverage, but also every single possible error being handled, or at least laid bare. If a program should crash upon particular errors, then the developer might say so explicitly, or otherwise provide logic to recover from those, without ever missing any place where things could go wrong. Contrast this made up language with your typical Java project: you might use the Spring framework and have a method that exposes a RESTful API that returns some JSON to the client. You'd be amazed at just how many different issues you can run into with even the simplest implementations, it's like a never ending path of discovering more ways for your programs to go wrong. If you can sometimes benefit from your IDE going "hey, this code might throw a NullPointerException", then how much additional assistance you'd benefit from (and how much error handling should be encouraged/enforced) is probably up for debate!

lmm 4y ago
> What if we had a language that only had checked exceptions and forced you to deal with anything that can go wrong. Launching a program? You better have some code to deal with an out of memory exception, or some code for dealing with a stack overflow exception. Working with some maths? Well, you better define what should happen in the case of number underflows or overflows, as well as division by zero or whatever else can be inferred by what operators you use. Dealing with a network? Well, be prepared to handle dozens of types of network failures, the brittleness of networks being laid bare to you. Want to deal with reflection? Well, there would probably be none, to avoid too much dynamic behavior. > It's rather obvious why we don't really have languages like that, but at the same time - if writing code in a language like that would be "possible", then surely there's a domain or two out there that might benefit not just from enforced 100% test coverage, but also every single possible error being handled, or at least laid bare. If a program should crash upon particular errors, then the developer might say so explicitly, or otherwise provide logic to recover from those, without ever missing any place where things could go wrong. A lot of functional languages go in that direction. E.g. if you stick to the non-IO fragment of Haskell then it mostly works like that - things that can error return Either that you have to handle explicitly, and while there's sugar to let you work with that in a similar way to exceptions it will never be entirely hidden. (Within IO you can have exceptions, of course; making a proper algebraic model of how e.g. network I/O works is pretty daunting). Idris or especially Noether go even further in that direction.