Fully agree with Axel Wagner. - I may make mistake in my library, ie my code found that some invariant is broken. If library is a "shared state manager" (for example, in-memory db, or on disk db), then I clearly have to stop whole process instead of continue to corrupt data (same as Axel's example) - I may give to programmer "low level" interface with access to internals (for performance). If programmer uses it in a wrong way, and my library's code detected that (but too late to return error, probably, by founding broken invariants), then it is clearly better to stop functioning.
In both cases I need a way stop process, and `panic` is a most clear way to do that... if no one calls `recover`. понедельник, 24 апреля 2017 г., 15:40:36 UTC+3 пользователь Kevin Conway написал: > > > 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....@gmail.com > <javascript:>> 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.
