> If so, then how should I raise unrecoverable error, if I really know that it is unrecoverable?
I don't believe you can ever know whether an error in your library is truly unrecoverable by the process executing the code. As a someone writing and operating the process, I'd expect a library to provide me all the tools necessary to make the right decision (such as custom error references or types) but never to make the decision for me. I've yet to find a panic that would not be better served as a returned error. On Mon, Apr 24, 2017 at 7:24 AM Sokolov Yura <funny.fal...@gmail.com> wrote: > > > Notice that real unrecoverable errors are not subject to defer/recover() > at all. > > If so, then how should I raise unrecoverable error, if I really know that > it is unrecoverable? >> >> Something like C style assert(): "guy, something goes completely wrong, > and it is > much better to stop functioning than corrupt your data further" > > > It's sometimes a perfectly valid and quite reasonable approach to defer > a recover() in an API function and panic(forWhateverReason) somewhere down > the call chain. > > A recursive descent parser may get much simpler and easier to code, for > example. > > I don't agree. I call it "abusing". In absence of other comfortable ways, > panic is abused to unwind stack fast (upto recover). > I could be mistaken. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
