[Surac]

for me there is a clear problem in all those languages. The exception paradigma opens a second way to exit a function. This is clearly a burden for every programmer. it is also a burden for the machine. you have to have RTTI, Inconvinient stack undwindings and perhaps gerneric types. Also nullable types are a but of a letdown. first we specify a "reference" kind type to neverhave to deal with null violations, then we allow NULL to express a empty state. Better have Result return types that carry a clear message: Result and Value. Also have real Reference type with empty and value. by accessing a empty value you get back the default value. i think c# has mastered that realy nice, but far from perfect

[mrkeen]

I was recently switched from Java to C# at work.

Initially I was impressed by the null detection. Then I found out about defaults. Way worse than null.

C and Go can demand a bit of ceremony with manual error checks. Things get bad if you forget to do the checks.

Java and Checked exceptions forced error-checking, which is a little verbose, and most of the time you can't 'handle' (for any meaning other than log) them, so you just rethrow.

C# went with unchecked exceptions. But with default values, there's no need to throw! Avoid Java's messy NPE encounters by just writing the wrong value to the database.

[neonsunset]

Default value is only relevant for structs. You can setup an analyzer rule to ban this for structs which have, say, an empty constructor. It’s a similar problem to Go and C++ except it’s worse in the latter two.

[zbentley]

But there are multiple ways to have execution leave a function.

The function could return.

The function could be aborted by SIGKILL.

The function could be aborted by a non-SIGKILL signal that preserves subsequent execution invariants.

The function could be aborted by a non-SIGKILL signal that doesn't preserve subsequent execution invariants (SIGSEGV in most--but not all--cases).

The function could abort(2) (not always the same as SIGABRT, but usually).

The function could overflow its stack (not always the same as abort(2)).

The computer could lose power.

...and that's without violating the spirit of the law with weird instruction-level stuff (e.g. is pop/jmp the same as ret? If I move the stack pointer and re-set all the argument registers, did I return?)