I hate the modern net so much.
Indeed. One thing that really pisses me off about these decisions is that the people who are doing it pretend they are taking input from the users, but, if you actually read the way it's worded, they've already made up their mind on what they're going to do. Making shit decisions and being coy/smug about it is really rubbing salt in the wound.
I am not at all surprised. Hey, guess who developed Go?
Fuck even all the good bits of C++ (boost) have been stolen by C++ (the standard).
Some languages denote error throwing methods with !. By standard they will have both versions available for every method. Languages like elixir handle errors much cleaner without relying on try catch.
Code gets ugly real quick with checked exceptions and try/catch/finally.
What do exceptions have that the ol' C-nile pattern
error_code = error_prone_function(arg);
if(error_code==SNEED){
return(FORMERLY_CHUCKS);
}
bool ret = false;
if (!foo())
goto end1;
if (!bar())
goto end2;
if (!baz())
goto end3;
ret = true;
end3:
// cleanup
end2:
// cleanup
end1:
// cleanup
return ret;foo();
bar();
baz();
return true;Your example is disingenuous. You claim C++ is "far cleaner" but you do not include how the C++ side actual handling looks. You handwave it away. That's exactly my issue here.
The fuck? Are you still in university? If you're not aware of the failure profile of the calls you make, you're an idiot. Handwaving this away with language constructs is how schoolchildren and Rust trannies "think". You don't solve problems by pretending they don't exist. You RTFM, handle the edge cases that can potentially emerge, and pray that the cases you can't imagine in your first implementation don't bite you in the ass.
One advantage of exceptions is that they're propagated up the call-chain until they're handled. This means you can write error-handling in one place most of the time and simply rely on exceptions being caught by the global exception handler instead of needing to fill your code with conditionals.
Good example. Thank you. You can surely implement such code in C, but I'd never choose C to do this, especially if you're doing MVC work, which is implicitly OOP. What language would you choose to implement something like this in? I reckon it would be a pain even in C++ or Java, but I know little about API endpoints for your choice of RDBMS and ES.
We're on the same page here. Never meant to implicitly defend providing LESS debug info, but that's kind of where I'm forced when I defend the C models. errno integer-constant errorcodes are adequate in their contexts, especially historically, but there are surely many cases where you want to pass more info, not less. Result types are surely how I'd resolve your concerns.
It's absolutely obvious. You RTFM.
If you don't grasp that we're discussing the topic of "how exceptions are handled" and that the handling itself is pivotal to the discussion, I see how you can think that failure profiles are not obvious: you seem to have language comprehension issues.
In Javaland, Spring provides the @Transactional annotation that makes this really clean to read and write. AFAIK it uses the PlatformTransactionManager bean along with some metaprogramming to implicitly pass all database calls to the transaction manager while in the scope of @Transactional and, if the correct kind of exceptional is thrown, call transactionManager.rollback(). Once execution leaves the scope of @Transactional, an implicit call is made to commit(). The underlying functionality isn't terribly complicated but the resulting code is much easier to read.
Even in the context of something like C, I'd prefer errors to be properly typed and type-checked at compile-time. Each specific kind of error should be a different type so the compiler can catch you when you're checking for the wrong kind of error. Of course, many C libraries and frameworks do this but a ton of C programmers still do shit the old way and it annoys me.
This explains a lot, thanks. My Java experience was over a decade ago working on a project where the DB2 requirement was explicit, so these layers are not well-known to me, and working in Java was so irritating to me that I chose to do anything else at that point.
Nowadays most Java code is database-agnostic. You typically use an ORM like Hibernate with a higher-level framework like Spring JPA to completely abstract all interactions with a relational DB. You write the code using derived interface methods or using JPQL (a query language that operates on the entity level instead of the table level) and hibernate automatically generates whatever flavor of SQL you need to talk to the database type specified in your application.yml.
Finally, some useful CS research.
The research is no good because it doesn't consider time. Consider this alternative hypothesis: