Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Theoretically they are different, in practice they are the same (it's just more difficult to handle panicking - sometimes you can't use catch_unwind because of it's trait limitations).

About race conditions: https://doc.rust-lang.org/nomicon/races.html



I feel like its quite difficult to call them the same in practice, when they serve very different roles: errors that are likely to be recoverable are not panics! in a sane rust api, whereas they very much are exceptions in sane C++. You recover from either in similar fashion, but panics! are intended to serve a much different role than exceptions (the common usage of exceptions in C++ being covered by Result<> in rust).


I hate when people use exceptions for regular errors, it triggers me hard. Please let's don't start this topic :)


You started it.... exceptions are mostly annoying because they are so verbose. Writing try... catch... is a whole lot longer than "if func() == null".


Exceptions are mostly annoying because they’re infectious, and somewhat undocumented (they’ve not part of the api; if an upstream library adds a new exception, all downstream code must now handle it [or document it]), and if anyone misses the update, its a runtime error waiting to happen. But notably, your compiler won’t say a word about it (unless its java, in which case you’ll probably get too much :-). Return codes are similar, but less cascade-y. Try-catch being verbose and fucking up control flow is just an added bonus.


Which is easier:

try: module.find_element() except: # handle not found else: # handle found

Or this:

if module.find_element(): # handle found else: # handle not found




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: